Changing backlog story point estimates mid way through a release

Question

Background: We are mid-way through a development which was estimated for a customer on a fixed price contract. To come up with the estimate we built a backlog by trying to list all user stories and then gave them a story point estimates.

We also tried to come up with an overall time estimate by taking certain stories, breaking them up into tasks of days/hours and then scaling the time to story point ratio up to the entire backlog. Because the technology and framework being used was not familiar to the development team (I know, I know...) the estimates ended up being more of a gut feeling guess. We did run spikes but they weren't entirely useful.

Anyway, now that we are mid way through the team have a much better understanding of the technologies and frameworks in use. We are considering re-estimating (in story points) the remaining items in the backlog.

There is some conflicting opinions in the team and some people feel we will lose track of the original plan and that 'you win some, you lose some' and it will all balance out. But at the same time it would be good to have a more accurate picture of our current progress.

My question: should we change the story points for backlog items once development is underway?

Considerations:

• Is this good or bad practice?
• If we do this, what calculations should we apply?
• Should we re-estimate the entire backlog including completed items, to make the things accurate.
• am I over-thinking this? :)

Answer 1

TL;DR

Regardless of your methodology, your project plan should be routinely refactored. In traditional project management, this often means tweaking start/end dates for tasks and milestones. In agile methodologies, this generally involves re-estimating user stories, throughput rates, and delivery dates.

The Value Proposition of Re-Estimating

Anyway, now that we are mid way through the team have a much better understanding of the technologies and frameworks in use. We are considering re-estimating (in story points) the remaining items in the backlog.

Congratulations! You have just discovered the value of iterative estimation in agile methodologies.

As projects progress, the cone of uncertainty usually narrows, and your team's accuracy in estimating work generally improves. Wikipedia says:

In project management, the Cone of Uncertainty describes the evolution of the amount of uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred.

In Scrum, individual stories are re-estimated each Sprint as they are peeled off the Product Backlog. Some level of re-estimation is also performed during Backlog Grooming, including the estimation of new epics or stories as they are added to the Product Backlog over time. However, the value proposition of re-estimating the entirety of the remaining Product Backlog is slightly different.

Goal of Estimating the Product Backlog

We are mid-way through a development which was estimated for a customer on a fixed price contract.

First, an estimate is not a commitment. While you may have agreed to deliver a fixed amount of work for a fixed price, unless your contract states otherwise then the delivery date of a fixed-price contract is usually flexible in at least one of the following dimensions:

• Scope
• Speed (e.g. the actual delivery date)

The value of re-estimating the remaining Product Backlog under this scenario is that you will now have more accurate estimates of:

1. the scope that can be delivered by a fixed date, or
2. the date on which the currently-defined scope is likely to be complete.

This provides transparency to the project, and gives the stakeholders levers to adjust the project as necessary. For example, a more accurate project estimate may allow them to make new cost-benefit comparisons about specific features or save money by terminating a project that has already provided sufficient business value to ship as-is.

Overly-Constrained Projects

If you unlucky enough to be managing a project that is simultaneously constrained in all three dimensions (e.g. cost, scope, and speed) then the only real value in re-estimating the project is to determine whether it will fail, how it may fail, or what needs to be re-negotiated to salvage earned value for the project.

If this is your situation, then the goal of re-estimating is to improve transparency and communications with the stakeholders. As such, doing the re-estimation clearly has value to both the team and the customer.

Answer 2

I faced the same problem with my team. What I learned is, if you're not comfortable with current estimates, go for it, but don't waste time re-estimating in-sprint or past stories. Focus on enforcing the basic rules of using points for new ones:

• choose a completed story S1 that everyone or most of your team is aware of the efforts involved to complete it. This is going to be your base to start estimating.
• define a point to this story, say 3 points, B size, or whatever metrics you use.
• define that new stories that are 3 points or B size will require the same amount of effort to complete as S1.
• This is the important part: define that new stories that are 1 point will require 3 times less effort to complete than S1. Stories that are 2 points will require two times more effort than 1 and less effort than S1, and so on. The same applies to sizes, if A size is the biggest one, define that a B size story should take an effort between A and C size stories. When in doubt, always bring back past stories estimates and compare with them (prefer the ones that everyone is aware of the costs).

Also, consider using regular backlog refinement meetings, there is no problem in re-estimating stories, I'd even suggest doing it very often to keep your backlog on track with reality.

Answer 3

should we change the story points for backlog items once development is underway

if this will help team and business folks to understand situation better - absolutely!

you might also want to consider aborting this sprint and start a new one (if change is big enough)