I’m not a fan of the #NoEstimates hashtag on Twitter. It turns out, after many blog posts and tweets, that #NoEstimates is a Contranym – a word that can function as its own opposite. #NoEstimates can mean no estimate or yes estimate – it is up to you. Sigh.
Continue reading
Tag Archives: estimating
What to do when Estimates go up a lot
You start the Sprint confidently but the burn down chart starts going up. Things are a lot harder than expected! Your velocity is lower than you expected. What to do?
Continue reading
Accuracy vs Precision in Estimation
Which is better: An estimate of “roughly 2 weeks” or an estimate of “4.75 days”? Personally I favour accuracy over precision. “4.75” is attractive because it very precise and a smaller number, but “roughly 2 weeks” might be more accurate. And estimating must be accurate to be any use for planning.
Continue reading
When Buckets Go Bad
I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.
Continue reading
Bucket Planning – Helpful Metaphor for Agile Release Planning
I sometimes call a Release Plan a Bucket Plan and the process Bucket Planning. I like the metaphor because if you overfill a bucket you end up with a mess on the floor – and the business gets that.
Continue reading
Three Ways to Control Scope in an Agile Programme
I both embrace change and also fight like crazy to reduce scope creep. On my current programme I use three main techniques to control scope: Programme Vision, Release Goal, and Requirements Trade-off. In different ways all of these put the business in control of what is in/out of scope. But they all help me stay within budget and time constraints.
Continue reading
Agile Requirements Snail: Feature to User Story to Scenario
The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.
I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.
The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:
Agile Requirements Snail
“Small” is an Estimate
One of the ironies of the discussion on no-estimates is that the no-estimate proponents do in fact estimate. In a small way.
Continue reading
Estimate To Inform Investment Decisions
Some people think estimating is “crystal ball gazing” (@agilemanager, 2 Nov 2012) leading to “bad decisions” (@WoodyZuill, 2 Dec 2012). I’m not one of them.
I don’t always estimate. Nor do I necessarily estimate everything. But I find estimating helpful when considering investment proposals. This is true whether picking the next user story or commissioning an entire project.
Admittedly estimating is not an exact science so I think George Dinwiddie (@gdinwiddie, 27 Feb 2013) summed it up nicely when he tweeted that “estimates turn the unknown into the unsure, based on someone else’s expertise”.
I believe that even estimates with caveats help the business make better investment decisions.
Continue reading
When To Measure Lean-Agile Productivity, and When Not To
Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.
There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.
Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.