Four Reasons Agile Teams Estimate Product Backlog Items
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 work, using?planning poker , the?fibonacci series , 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 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 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. 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.
What Do You Think?
Which of these four benefits to estimating helps your team the most? What objections to estimating has your team given? Were you able to persuade them to estimate? How? Please share your thoughts where this post was originally published, on the Mountain Goat Software blog .
If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them."
Information Technology Professional | Builder of High Performing Agile Teams | Innovative Servant Leader | Balancing Strengths and Strategic Goals
2 年-unless you are an executive, customer, or in sales and marketing and only want to know if it's done yet. All the rest of this information comes across to others outside of IT like Charlie Brown on the telephone.
Certified Project Manager and Scrum Master | Agile & Waterfall Project Management Specialist | 20+ Years of Leading High-Impact Healthcare IT Projects
2 年Point #2 (stop and think) is perhaps the most important IMO. Asking a team for an estimate, whether points, hours, days, whatever, creates accountability. The best conversations come out when team members disagree about an estimate.
Creator of AI Software Requirements Analysis Tools - automated estimation, QA and insight.
2 年Totally agree that there are several benefits with the process of estimation. I prefer COSMIC Function Points CFP over Story point sizing, but much of the value is in the thinking, conversations and shared understanding that comes from it. We have taken this to whole new level with AI requirements analysis at ScopeMaster.
Breaking down the e-commerce monolith one bounded domain at a time
2 年"This team has established a track record of being good at?agile estimating" Or rather they got lucky a few times in a row, or have learned to pad estimates and use Parkinson's law to their advantage. Not a good source of 'credibility'. Any long term estimate is by definition flawed, and thanks to the cone of uncertainty, eventually meaningless. I'd rather credibility came from stakeholders trusting the team to work with them, day in, day out, to reach a common goal, continuously adjusting the direction of travel as the work progress. I don't mind the other reasons so much, tho don't believe the 'agile' estimation theatre is the best way to go about it. Helping the team's introspection, visualising the work through various angles, lenses and level of detail is essential to reduce the "unknown unknowns" that might throw the work in jeopardy. "Stop to think", "help the scrum PO to prioritize " are a given for an agile process, although really, the PO should prioritise based on the value stream, rather than the effort required delivering it. If we believe something is valuable to our customers then this is where we should put our effort in, rather than pad our sprint with smaller easier items of lesser value. Imo anyway ??