Menu
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?
615
A reasonably fully stocked product backlog is written before the first sprint begins and all items are estimated before the first sprint planning meeting. [If you do this, be careful not to write all user stories with too much detail. Each product backlog item you write represents an investment.
In Scrum Projects, Estimation is done by the entire team during Sprint Planning Meeting. The objective of the Estimation would be to consider the User Stories for the Sprint by Priority and by the Ability of the team to deliver during the Time Box of the Sprint.
Usually, the estimation is done in two levels are for the PBI's at the story level and the sprint backlog at the task level. You do the estimate of the user stories in the PBI's when you have prioritized the items and are done with story point estimates as discussed above.
The product backlog never ends. Its like a alive organism, he is aways getting bigger while the system is alive. Even if the project get ready, the product backlog still alive.
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.
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.
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.
188
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
