Search code examples
timeagilescrumestimationyoutrack

Scrum Time Estimation - Team Size


We have a team of about four developers working in Scrum with two week sprints. We use YouTrack and when performing time estimation in Sprint Planning, we hit the two weeks of work quickly.

The issue is, for example, developer John will pick the first item on the backlog and say it'll take about 1 day. Developer Brian will take the next item and say it'll be about 1 day. Of course, that's actually only one day's work if each developer works on each piece, but YouTrack will sum it as 2 days.

When the whole team doesn't have to work on the same item at once, how do we appropriately estimate time? Are we breaking Scrum rules somewhere?

If we're doing it right, and we have to just go over two weeks, how do we be sure we're not giving ourselves too much work?


Solution

  • As far as I know and understand, you don't estimate effort in Scrum. You estimate complexity of user stories in relation to each other and the contained functionality.

    Following this, you estimate story points, not man days. The burndown chart shows your team's progress. Over time you get quite an accurate team velocity which basically tells you how many story points your team gets done with per sprint.

    Use this team velocity as a basis to decide whether to commit to another user story for any given sprint, or if it will probably be too much.