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:
- 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:
- the scope that can be delivered by a fixed date, or
- 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.
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.