When talking about estimating with story points, I’m often asked: Why should a team estimate at all? Specifically, why should a team estimate its product backlog items?
I can think of four good reasons to estimate: credibility, deeper thinking, prioritization, and insight.
Estimates Create Credibility with Stakeholders
The most compelling reason is that good estimates can help a team to establish credibility with stakeholders. To see why this is important, let’s consider a scenario that might be familiar to you.
Someone in your organization needs a new project delivered in, let’s say, four months. This could be an entirely new product or an enhancement to an existing one.
Your team estimates the effort required to deliver the work, using planning poker, the fibonacci sequence, or some other methodology. And team members conclude that four months is impossible. Six months seems possible but eight seems much more likely. The team goes back to the stakeholders and tells them it can’t be done in four months. Instead, they explain, it will take six to eight months.
In response, the stakeholders tell the team to do it anyway, and that they expect it to be delivered in four months.
The stakeholders are essentially ignoring the team’s estimates and plan. They’re doing this because the team has probably demonstrated, over and over again, that they aren’t very good at estimating. The team’s track record is probably one late project after another.
And with a track record like that, the team is not viewed as an equal partner in negotiating dates. Since the team has demonstrated that they don’t really know what can be delivered in a given amount of time, stakeholders don’t put credence in its estimates.
Now imagine a different situation. The team has gotten better at estimating–not perfect, but better. They said one project would take three to four months and it did.
Another time, they said a project would take four to five months, and they were only two weeks late. They finished an iteration early on a five-to-six-month project. And the team finished yet another project on schedule, despite unexpected new features being added during the project.
This team has established a track record of being good at agile estimating. When this team says the project will take six to eight months, stakeholders listen. They might be disappointed. After all, they wanted it in four months. But stakeholders in this situation with this team are far less likely to steamroll the team and tell them to just go build it in four months anyway.
This team deserves to be treated as equal partners in the project of figuring out what to do when more is wanted than there is time to build. The only way to become this team is to get good at agile estimation and forming plans from estimates.
I think this is a pretty compelling reason to estimate. But let me lay out three more reasons why teams working on agile projects should estimate their product backlogs.
Estimates Ensure Teams Stop and Think
A second reason is that the act of estimating will make the team smarter about the work they estimate. I think it’s just human nature to think more carefully about our work if we’re giving an estimate to someone.
When I provide that estimate for a user story, I want to be right, or at least close. Accountability makes me think more deeply and thoroughly about the work, especially the work of a cross-functional team. Apart from yielding a good estimate, this thought process eliminates a lot of the big surprises that really blow a schedule.
Our third and fourth reasons won’t apply to every team, but if they do apply to your Scrum team, they’ll be important reasons for your team to estimate.
Estimates Help Product Owners Prioritize
The third reason teams estimate their product backlogs is to help their Scrum product owners prioritize. The estimate assigned to a product backlog item during product backlog refinement will influence how the product owner prioritizes the item.
If an item is estimated at 5 points, the product owner may want the team to do it next iteration.
If it’s estimated at 50 points, the product owner will likely put it lower in the product backlog because there are probably a few other items that are more valuable considering that this item costs 50 points.
And if the item is estimated at 500 points, the product owner will likely put it near the bottom of the product backlog–or perhaps just throw it away if it’s going to take that long to develop.
Estimates Provide Insight into Delivery
Finally, our fourth reason to estimate is to enable us to answer questions about when and how much can be delivered.
Many—perhaps most—teams are asked questions such as
- When can you deliver all of these features?
- How much of this can you deliver in three months?
When the product backlog has been estimated, the team can answer these questions.
If the product backlog has not been estimated, the team needs to fall back on traditional task decomposition at the level they'd typically do at sprint planning to create the sprint backlog. (In the Scrum framework it's common to have two different levels of planning.) They’ll have to examine each product backlog item, decompose it into tasks, estimate each task, try to discover what they missed, add some amount of fudge factor, and use all that to try to answer those stakeholder questions.
Breaking each product backlog item into tasks and estimating all those tasks is much, much more work than directly estimating each product backlog item with story points. And we can actually estimate more accurately at that higher level because it’s not reliant on completely identifying all the sub-tasks. Tasks change as work progresses, after all.
Credibility Is Key for Agile Team Success
Of these four reasons to estimate the product backlog, I find the first to be the most compelling. Until your team establishes a track record of providing good estimates and plans, the team won’t be treated as an equal partner in negotiating deadlines.The consequence is you’ll have little or no ability to push back against unrealistic deadlines that are imposed on the team.
