Evolving Estimation Process

I took the photo of one of our product development teams yesterday. What I hope you can see from the photo is engagement of everyone in the conversation. It's quite unlike many tedious story estimation meetings that I've been in at other organisations. Often developers are in a room for a long time putting numbers on user stories and gradually losing the will to live.

We used to have a similar long session every few weeks to estimate a big batch of stories before selecting those to work on next. Our Product team used to meet with stakeholders and write up details into TargetProcess only to discover that not all the information developers needed was available at estimation time.

Over the last year we've evolved the way we work. Developers sign-up to do preliminary investigations on each story with the aim of discovering whether it's feasible and worth investing development time in.

We have a regular 30min Story Time slot after lunch on Monday, Wednesdays, Fridays. If there's a story "Ready for Estimate" then we discuss possible approaches and how to break it down. The purpose of the meeting is to get a broader opinion on how much development effort is likely to be involved. These meetings are held in the Dev area and often involved sketching on the whiteboard. The developer who did the preliminary investigation leads this. If there's no valuable stories ready then we skip the meeting.

The teams estimate in points which are roughly ideal pair days. We used a blind-voting technique but not with poker cards - we use cheap mini sketchpads - these are erasable and hang on hooks next to our team boards. Here's Jahed, Jason and Tim with theirs.

We don't get into a detailed design discussion, this only happens when we start work on developing the story and that only happens if the estimated story gets prioritised by our stakeholders.

The result is that estimation has become a small part of our Story Time discussions - these meetings are now short and sweet only usually covering one story. Would love to hear whether your teams do anything similar.

Comments

[Vasco Duarte]

Great post with your story about how you are evolving the Story estimation process.
However, I'd like to point out that there's another aspect you do not cover here: Project estimation.
I've been working with #NoEstimates at project level, to help predict - based on data - when we are "on time" or late. The key aspect here, in my experience, is that the data we collect helps us either verify our original goals (time, scope) or it helps set goals (time and scope) that are supported by evidence.
How do you estimate a release (several iterations, not just delivery of software)? Or are you already at the continuous delivery stage where this is not a relevant question?

[Rachel Davies]

Good questions, Vasco. I perhaps should've mentioned that we're more in #NoProjects camp. We release features as soon as they're ready and don't make plans at the feature level further out that 2-3 weeks. Last year one of our other teams did have to do some date prediction for a launch event and we used a Cumulative Flow Diagram.

[J. B. Rainsberger]

This sounds like what I'd expect a mature XP-oriented team to do. It sounds like you use estimating to catch wildly different interpretations of a story, and you explicitly mention examining stories for feasibility and, I can only guess, nasty surprising lying in wait. My primary reason for encouraging #noestimates has to do with moving groups away from the illusion of accurate long-term planning, so since you don't have long-term, detailed plans, I would have no reason to discourage you from estimating. :) It sounds great!