Scrum - When do you Estimate the Effort for Product Backlog Items?

Question

At which part of the Scrum process does your team make educated estimates as to the effort required to complete a given product backlog item?

For example, say you have a product backlog item that says "The user will be able to supply their email address and receive an email with a link for resetting their password" scheduled for Sprint 1.

Do you start the sprint with a very rough estimate and refine it? When does this "user story" turn into granular action items that a programmer can estimate in time? (ex: "Build web form with one text box and submit button" = 2 hours)

Do you do the finer, more accurate, estimates before the sprint begins? At the beginning of the sprint? Or during the sprint whenever the designer/programmer finally bumps into the task?

Answer 1

The rough estimate should be done before the sprint planning where this particular item is supposedly picked by a team. Usually we check the product backlog out during context switches or downtime during a sprint to do rough estimates on new items in "story points", so the product owner can prioritize them properly before the next sprint planning.

Our sprint planning is usually time-boxed to 2 hours in the beginning of a new sprint. This is when we meet with the product owner(s) and pick items from the backlog, most of them roughly estimated and correctly prioritized. Missing estimates are done on the spot and then we do the "fine-grained" tasking of the stories within this time-window (which is usually quite intense work) leveraging the fact that the rest of the company is aware of this and POs and stakeholders are available to sort out unaccounted for details.

Of course, sometimes the implementation task sequence will differ from the planned tasking, then it has to be adjusted, and the burndown chart might need to be retuned.

Burndown in tasks We simply use number of tasks for our burndown measure. Usually you do something like actual hours or ideal hours, but this was good enough for us and apparently interesting enough to need some clarification.

We do not estimate time on these tasks, all that matters is the story point estimate (the rough estimate) on the story, which we put in ideal man days.

How that story is split into tasks is more of a team distribution and general progress indicator thing and not so much making accurate hour-estimates for us.

In the end we have handled x amount of story points and get our focus factor from that in relation to the actual available man days in the team that sprint.

In the end the rough estimate in story points is what we base our story selection on (ie, how many sp we can do in a sprint). We tend to get better at the rough estimate - and I think this is important because the product owner prioritizes items in the backlog mostly based on this, and never based on task estimates anyway - because that's team internal.

As the tasks have no explicit time estimate on themselves, the focus is on the rough estimate in story points. If the tasks together takes more time than estimated story points * focus factor, we simply did the rough estimate wrong or should have corrected it during sprint planning when most information should have been available or sorted out.

Answer 2

At the moment we produce detailed task breakdown and estimates before the sprint starts. This is for 2 reasons:

1) Our business want the estimates to help them decide the priority.

2) The development teams are under a pressure to deliver to the estimates and to not deviate from the natural burn down.

In my opinion this is the wrong approach as it removes the ability to be agile. I think the process should be more like this...

1) The business should use the fibonacci numbers produced during the planning meeting to help them determine priority. Or at least only expect a 'finger in the air' estimate from the dev team.

2) The burn down chart should be seen as a guide to how the project is progressing to indicate whether more PBI's need to be added or lower priority ones dropped and not as a firm 'target' of what will be completed.

Working this way would allow us to spend much less time in planning and design. We would still produce a high level estimate at the start of the sprint which could be refined as the sprint goes on.

I will be interested to get comments on this before I have the battle with my business.

Answer 3

Usually, estimation should be done in 2 levels at the start of each sprint: story level and task level. For best results, product owner and team should do both together, every time, although sometimes it is acceptable for the team estimate at task level without the product owner present.

Project Estimation / Roadmap Construction (Story Level)

On your first sprint, you have to estimate at least 80% of the backlog items (I'm assuming the Product Owner already had it prioritized) to build a reasonable project roadmap, which will consist of stories grouped in sprints and a initial estimated projection of the project length.

At this moment, the estimation of each story is done using, not hours, days or week, but a relative unit for size (which encompass effort, complexity and risk all at the same time), such as story points. We use the Fibonnaci scale and Planning Poker for this phase. It is important that the whole team actively participate in this process.

After that, the team has to guess how many stories they are able to complete in the 1st sprint, which will be their initial estimated velocity (points/iteration). Usually, it is best not to use 1-month sprints but rather a 2-week or 1-week sprint length to improve estimation accuracy. The 1st planning will usually take the whole day or even 2 days, depending on backlog size, team size and the length of the sprints.

After this 1st round of story estimation, the product owner together with the team might want re-prioritize the backlog to optimize the cost/benefit ratio, so the might be some back and forth until there is an agreement.

You should end up with something like this:

PROJECT ACME ROADMAP

SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)

SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)

SPRINT 3 (39 points)
--------
...

On the following sprints, this roadmap will be revised over and over, at the start of each sprint, adjusting the velocity to the actual velocity that the team is obtaining and re-calculating the project length as needed. Sometimes, re-estimating the stories is necessary as well, as the team evolves and requirements change. However, the time to revise the roadmap should be no more than half a day.

The progress at this level should be visible to stakeholders using a burndown chart, where the X axis are the sprints and the Y axis are the story points.

Sprint Estimation (Task Level)

The 2nd part of the planning phase for each sprint is spent breaking down each story into tasks. Here, tasks should be highly technical in nature and estimated using hours. We have a policy that if the task is estimated longer than 8 hours, then it needs to be broken down into more detailed tasks no matter what. The result will be the sprint backlog, with tasks grouped by story, and the sprint burndown chart, where X/Y axis should be days of the sprint and hours respectively.

It should look like this:

Sprint 8
--------
Story 17
  Task 1: 8 hours
  Task 2: 6 hours
  Task 3: 2 hours

Story 18
  Task 1: 8 hours
  Task 2: 6 hours

Story 19
  Task 1: 6 hours
  Task 2: 3 hours
...

So basically, these are the 2 types of estimation you should be doing at the start of each sprint, where usually the 1st sprint requires a little more effort to build the initial project roadmap.