Why and How to Estimate in Agile?

I love this post, Why Estimate? It's a topic I've confronted at organizations adopting agile and I hear all the barriers, "it's not accurate", "don't hold me accountable to it", "isn't estimating a waterfall process?"...

Mike's points are dead on. You estimated to help make decisions on what NOT to do. If a feature is broken down to12 stories estimated at 150 points and the team's velocity is 75, then the product owner knows that it will cost her at least two sprints for the feature. Why "at least"? Because the feature's full sizing can only be determined once the requirements are fully documented in the stories and in my experience, the full sizing only goes up once these details are flushed out. But the point is, if the product owner finds the estimate too expensive, she can either lower its priority (e.g., don't do it) or simplify the requirements (which should lower the estimate).

The Agile Estimating Process

Here is the process I advocate:

  • Teams, departments, or organizations should define metrics and a process to derive or demonstrate business value. The product owner is expected to prioritize the high-level feature backlog based on the business value.
  • On seeing a new feature prioritized, the leader(s) from the technical team should break prioritized feature on the feature backlog into Story Stubs - story names, without details. For "simple" features, this usually isn't a difficult task for experienced teams but for more complicated ones -
    • It may require sessions with the Product Owner to get some more details
    • It may require breaking down the feature into smaller ones, some that might be easier to break down and be more important. 
    • It may require some R&D (spikes) to help flush out an approach.
    • It may fall out of scope for what the team (or teams) can perform - either by size, skill, or complexity.
  • Assuming the feature now has story stubs, the leaders of the technical team should now be able to assign estimates to the Story Stubs.
  • Mature technical teams will often review story stub estimates. Is the feature fully broken down? Are there architecture considerations? Should technical debt be addressed with the feature? 
  • The Product Owner should then review, and has several options:
    • Accept the estimate and move the stories to the story backlog. (Note: on the story backlog, a separate process should be used to document the stories with acceptance criteria and to size the story.)
    • Lower the priority of the Feature or remove it from the backlog.
    • Discuss the estimate to see if assumptions were wrong, or if the feature's definition can be simplified and yield a lower estimate. If this path is taken, the newly refined feature should be prioritized again on the feature backlog for a second estimate.

Why Estimation works?
  •  It's only done after the Product Owner has prioritized features by business value. So the most important features are estimated.
  • Good estimates require some thinking. Breaking the feature to stories and accounting for some of the complexity is one way to ensure that estimates are grounded in some reality. Contrast this with an estimate at a feature level - "that looks like three sprints" - that provides no details or assumptions.
  • Stubbing and estimating are low-cost activities - often involving only the technical lead for the team. The activity can be time-boxed. If the feature is expensive, it can be reevaluated or killed without too much investment.
  • Going back to the first point, the process forces prioritization - first to get the feature estimated (don't try to estimate everything because estimates require some thinking!) and then to review/prioritize before adding the stories to the story backlog.
  • It also forces good behavior - if the product owner asks for too much and the estimate is high, the process to simplify the feature definition and estimate again will delay the development of the feature. Hopefully, this encourages the product owner to request minimal feature sets. 
  • Stories that make it to the story backlog go through a more expensive process - writing, reviewing, and sizing the story. Again, this process ensures that only the most important features, now with accepted estimates, are sent to the story backlog.
  • The features, broken down with stubs and estimates provide an architecture team visibility into future needs. It gives them room to consider future architecture needs and processes to ensure architecture requirements or technical debt are factored into estimates.
  • Ultimately, to the extent that "estimates" are not as accurate as "sizes" (again, sizing in this process is done on the full written story, by the development team, and for stories on the story backlog) - the product owner has a second chance to review and prioritize based on this added information.

So if you're only sizing fully written stories, consider implementing an estimating process to make teams smarter and more efficient.

1 comment:

  1. Some of the good points are being discussed here to act on the estimation of agile software development and this can be more accurate if more information is being provided to you.


Comments on this blog are moderated and we do not accept comments that have links to other websites.


About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.