A project is incepted with a story list that has all the stories estimated. The team has completed 4 iterations and there are 8 more to go. The team also has usual churn of people. Are you in favor of or against re-estimating stories during next sprint planning?
Practioners are on both sides of the fence on this one. Some recommend re-estimation and some want to stick to the original estimates.
A colleague of mine recently explained why he is not in favor of re-estimating. He said, "I don't want to have to explain to the project sponsors why the project estimate just changed from 133 points to 97. Do you think the scope has changed?" That was a very insightful discussion. He then said that if the team is not finding the big stories as big as they initially thought, it won't matter. That simply means the team is now burning more points of a larger scope number. This will proportionally be the same as burning less points of a smaller re-estimated scope.
Re-estimation is a tough thing to convince people on. I still see a huge benefit in it.
- The idea of re-estimation is not about lowering or increasing the numbers; it is about estimating the relative size of the stories.
- The stakeholders/sponsors, ideally, should not be concerned about total point scope. This is an internal number for the Dev team. Sponsors should just be concerned about the rate of progress towards delivering a product.
- Keeps the relative size of stories up to date,
- Makes it almost mandatory to revisit the release plan, and
- Promotes conversation.
Relative size is a big thing to watch out for in situations where new stories are added or existing ones are split. The reality of agile greenfield software development is that the initial brainstorm hardly ever reveals all the stories. Total effort, as estimated, at the beginning of the project will most likely change (increase). An initial estimate that is not changed with the lessons that have been learnt in the last few iterations is not acknowledging that:
- Work done in the last few iterations can be leveraged,
- Assumptions with initial estimates may have changed.
Typically, teams start with developing the simplest functionality first. Let's assume that Story A is the simplest functionality and is 1 point. And, the initial estimates had story B estimated at 3 points thinking that this is three times the size of A. Why would I not want to re-estimate B as a 2 if I now know that is twice the effort of A and not three times the effort?
One of the biggest benefits of re-estimation is that it reevaluates a team's progress towards the end goal and indicates if you are on track or not. Not re-estimating will increase the probability that one of the stories a few iterations down with an initial estimate of 2 points will now take 5 points worth of effort. There may be many more such sitting in your pile of stories. Example Problem: Let's say that you have a 1000 sq. ft. backyard that needs to be landscaped and upgraded with a water fountain. You hire a contractor and (s)he gives you the following story list:
- Tilling out existing grass - 2 pt
- Discard old grass - 3 pt
- Transporting grass to backyard - 1 pt
- Laying out and setting the grass - 4 pt
- Edging the grass - 1 pt
- Post installation cleanup - 2 pt
- Fountain Installation - 2 pt
That's a total of 15 pts. Your contractor also tells you that last time they did a similar backyard it took them a day to till and clean (stories 1 and 2). Based on that the plan will be:
- Day 1 - Story 1, 2
- Day 2 - Story 3 , 4, 5
- Day 3 - Story 6, 7
You as the sponsor/customer now have a plan and expect the backyard to be ready in 3 days (iterations) assuming a 5 pt velocity based on the contractor's past experience.
Work starts, and you now request the contractor for two new things. You want the lawn to be leveled in a different gradient and you also want the soil to be fertilized. These are two new stories that get added to the story list.
While tilling, the contractor also finds out that the soil has lot of gravel and stones in it. Scenario 1: No Re-estimation When there's no re-estimation, the story list will likely be as under. The team will estimate the new stories.
- Tilling out existing grass - 2 pt
- Discard old grass - 3 pt
- Transporting grass (sod) to backyard - 1 pt
- Laying out and setting the grass - 4 pt
- Edging the grass - 1 pt
- Post installation cleanup - 2 pt
- Fountain Installation - 2 pt
- Re-level lawn - 1 pt
- Fertilize Lawn - 1 pt
Total scope is now worth 17 points. Based on a velocity of 5 pts. the team will sign-up for stories in the following order:
- Day 1 - Story 1, 2
- Day 2 - Story 3 , 8, 9, 4A
- Day 3 - Story 4B, 5, 6
- Day 4 - Story 7
I split story 4 into 4A and 4B, both of which are 2 pts and they encompass laying out and setting grass in half of the lawn.
From the plan it seems that the team will take 3.5 days to finish the job. However, story 3 & 6 have not taken into account the fact that now the scale of the problem has changed. It is just not cleaning and hauling grass, but also gravel and stones. Scenario 2: When we Re-estimate When we re-estimate, the story list will likely be as under. The team will estimate the new stories.
- Tilling out existing grass - 2 pt
- Discard old grass - 3 pt
- Transporting grass (sod) to backyard - 3 pt
- Laying out and setting the grass - 4 pt
- Edging the grass - 1 pt
- Post installation cleanup - 4 pt
- Fountain Installation - 1 pt
- Re-level lawn - 1 pt
- Fertilize Lawn - 1 pt
Total scope is now 20 points.
Story#3 is now 3 points because the team just figured out that transporting sod to the backyard in absence of a wheel barrow is not 1 point but 3 points. Story#6 is 4 points because post installation cleanup is not just grass and dirt but also gravel and stone cleanup, without a wheel barrow. Story#7 is now 1 point because we just gained plumbing skills and found a water pipe running in the yard, closer to the fountain.
The new plan is:
- Day 1: Story 1, 2
- Day 2: Story 3, 8, 9
- Day 3: Story 4, 5
- Day 4: Story 6, 7
Traps of Not Re-estimating
- When we don't re-estimate it seems like we can finish the job in about 3.5 days. If the Product Owners request additional scope of 2-3 points, I would have no problems accepting it. My plan tells me that I have a little over half the day available.
- A new story estimated at 1 pt should roughly be the same as an existing story of 1 pt in effort. But it won’t be the case here; at least it won’t be reflected in the metrics. The idea behind agile project metrics is to make knowledge very explicit. Not re-estimating fails to achieve that goal. Estimate and velocity metrics become very tacit.
- As a team member my level of trust in the estimates goes down. There are two 1 point stories, but they are not the same effort. One is a new story and, hence, has a new estimate, whereas the other is an old story and is not re-estimated.
- There may be stories that have initial estimates that are much higher than the effort expended on them now. These may not be included in Sprints because they will increase the Sprint sign-up points to go beyond the target velocity. The tendency is to avoid signing up for these stories.
- Agile Software Development is also about adapting. Not re-estimating will lead us to become non-adaptive.
On big projects where number of stories for each release easily run into 3 digits, these traps amplify themselves. The benefits dervied from re-estimation may not always be so obvious, but they for sure increase the level of comfort and confidence in the team.
Picture taken from: http://www.stellman-greene.com/blog/wp-content/uploads/2007/05/schedulereview13.jpg
