« Kickstart Your Retrospective with Continuous Timeline | Main | The Art of Embracing Change »

09 October 2013


Feed You can follow this conversation by subscribing to the comment feed for this post.

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!

The comments to this entry are closed.