Part 1 of my Estimation Series

A while I go, I wrote up a bit of a rant on a crazy estimation scenario that was presented to me by a colleague. If you didn’t get a chance to read it, you can find it here. We’ll call that rant Part .5 of this series of blog posts on estimation.

Since then, I’ve seen a bit of a swell on twitter of the #noestimates hashtag and a lot of discussion on topic. I was recently saw a tweet from Allan Shalloway that prompted a bit of a conversation:

(click imagine to see original tweet and conversation)

As you might have guessed, my thinking is more aligned with the #noestimates crowd and I’ll elaborate that over the coming months here, but this tweet started a conversation that I’ve had before.

Why do you estimate?

If I’m going to encourage you to stop estimating, it’s really important that we understand what I’m encouraging you to stop vs. what you might actually be doing.

As the conversation continued, Allan stated:

…which made wonder if we’re confusing prioritization with sizing, which is actually quite common.

So I won’t re-post the entire twitter conversation here, but I’ll start to share my thoughts on the why of estimate.

Intent

When I engage in an “estimating” exercise with a team, I very often try and restate the activity as a sizing exercise. For me, this starts us down the road of using the language that more accurately describes the end goal of our exercise. We want, to the best of our ability, describe how “big” we think this work item is. I’d like the team to use their past experience and compare the current work item (requirement, user story, etc.) against similar work items they’ve worked on before. This is a relative sizing technique that is used all the time by other agile methodologies such as Scrum or XP. You’ll often here the term “yesterday’s weather” in the same conversation about agile estimation techniques. The best predictor of today’s weather is yesterday’s. The team’s recent experience is the best predictor of its near-term current capabilities.

To me, the really important point of this exercise is sizing! Not scheduling. Not prioritizing. Those are completely different activities! The product owner/business representative on the  team will tell you, perhaps with size as a decision input, what is next and when they might hope for it to be done. I generally expect them to help the team constrain the story, but the delivery team are the ones that are responsible for determine the size of the story.

So in my mind, the intent of the “estimation” exercise is to allow the whole delivery team to determine the relative size of the story compared to work items they have done in the past.

Why?

So why are we asking delivery teams (Development, Ops, anyone who is creating value) to size their work items? This is where I think all of the estimation craziness and problems start.

We need to provide some sort of indication of the anticipated financial impact to the organization making the request of this work item. We also need to provide information that would allow us to set a delivery timeframe expectation. And the next level of this problem is to take 100s (or 1000s) of these work items and provide the same financial and delivery timeframe expectations. This is, for most teams, really really hard.

And I will state that it is my belief that size is not the primary factor in determining cost or delivery timeframe. Will a bigger story cost more? Usually, yes, but not always. Will a bigger story take longer? Usually, yes, but not always. What if to delivery a story, a team has no external dependencies? What if it does? What if the story is big, but a really well known problem? Unknown problem? What if the team is missing a team member when it finally pulls the story from the backlog? What if the team composition has improved?  There are so many things that can change the cost and expected delivery timeframe in addition to the size of the story that are very difficult to predict.

So in my mind, we are trying to size our work so that we can help business decision makers make the best decision for the organizations economic well being.

Final Thoughts

I’ll leave you with a couple homework questions. What is the intent of your team’s estimation exercises? Why is your team performing those exercises?

Part 2 will explore my approach to providing business decision makers with better information so that a team (business and delivery groups) can make better decisions on behalf of our organizations.