Estimation Revisited (Part 1)

In a previous blog post, I explored the challenge of wanting to be agile, but also wanting certainty. One place this shows up is in how we deal with estimation. In this blog post I take a deeper look at estimation and projections.

At ISE, we have an Agile Community of Practice (CoP). The CoP is a place where we share learning and support each other. Attendees include Scrum Masters, Product Owners, Developers, and occasionally other team members. In a CoP discussion I asked the attendees to briefly discuss highlights and “lowlights” regarding estimation and projections. As context, most of the teams represented use story point estimating and track velocity as a way of attempting to estimate how much can be accomplished over time.

Here’s a sampling of what came out of the query:

• It is not very useful to put estimates on bugs – we don’t know enough at the start of a bug investigation to get anywhere close. Support work is very similar.
• An expectation that estimates are equivalent across teams doesn’t work.
• Relative sizing is useful; we’ve found value in “the estimation game” approach of ordering items by size and then adding the point value boundaries.
• Break items down small enough.
• Estimates are hard enough; if a team isn’t stable it gets even harder to project when things might get done.
• Newly-formed teams have no established velocity; and projections made are wildly inaccurate.
• Stakeholders sometimes view estimates as commitments. This creates pressure to “get the work done” vs. “getting the work done right”.
• One useful aspect of attempting to estimate work is that it helps the team understand the work better.

Underlying Concepts

Coming back to the essence of estimation, we reviewed some underlying concepts…

What is an estimate?

• Our best guess, based on what we know today, of what this work will take.
• When we make an estimate, we want to include effort, time, and complexity.

Why estimate?

• Stakeholders want to be able to make decisions.
  • For example: “When can we get X?” and “How expensive is X?” may drive decisions about whether to do X, whether X is worth doing now, or whether to make adjustments to capacity.
• Estimations help teams decide what to take into sprints.
  • When do we break it down smaller?
  • One experiment: what happens if we break everything down into 1 and 2 point items?
    • Lean principles suggest reducing variability and “batch size” – if everything is “small” then we achieve that.
  • How can we break it down? One good resource is the Agile for All Story Splitting resource.
  • One experiment: What if we consider a spike as a last resort strategy to learn something? Instead, can we learn something while building something of value?
  • Is this item too big?
  • How fast are we going? Will one more story fit in this sprint?
• Estimations help reveal our differences in thinking and more clearly helps us understand the work (e.g. using Planning Poker)

What can you estimate?

• Support work and bugs: we may get more out of using our cycle time and average flow to estimate this kind of work than attempting to estimate individual items.
• For feature work, we can estimate epics & stories.
  • At the epic level, t-shirt sizing can be a useful place to start.
• For exploratory work such as scalability, we can estimate the work we know, but we also know there is more work that we have not discovered yet and we won’t know what it is until we do some of the work.

Can you change estimates?

• “Agile” (e.g. the Scrum framework) doesn’t tell you either way; a good question is: what will be most useful for helping you meet the estimation goals?
  • It’s useful to explore “why” a story seems much different than we estimated – this can be a place of learning.
• It can be useful to maintain example stories (reference stories) – e.g. “here are examples of 1, 3, 5, 8 point stories for use when estimating new stories”.
• Did the story have a scope creep?
• It may be useful to re-point as a reference: here’s an example of a 21 point story.
• Exploratory questions: Is this happening a lot? Or infrequently? Would we make the same estimation error again? What can we learn?

How to address estimation / projections with stakeholders?

• Core Concern: stakeholders can conflate estimates with commitments. Some stakeholders are not well equipped to handle uncertainty.
• This may mean that we need to educate stakeholders about uncertainty and its sources and implications.
• Uncertainty is higher in the Cynefin Complex domain. We may need to have a conversation about in which domain(s) our work lies.
• One possible conversation: “This is an estimate / projection / forecast. It is uncertain. We know something about how uncertain it is. How will we collaborate to address how we will adapt to the fact that the estimate is wrong and uncertain?”

Can we use velocity as a metric for “is the team improving?”

• This is tricky. A team might internally use velocity as a metric to drive improvement, but when imposed externally this can create a negative incentive that reduces the quality of estimates and the quality of work.

Taking a Deeper Dive

In my next post, I’ll explore three topics that arose in follow-on conversations.

• Dealing with Uncertainty in Estimates
• Complexity
• Stakeholder Discussions

Check back for part 2 in the Estimation Revisited series.  

Originally published September 26th, 2019 on the Innovative Software Engineering blog. Republished with permission.