Despite the current #NoEstimates trend, at Unruly we still estimate our user stories. The way we do this is in small informal meetings in our development area. Why do we find this useful? Because estimates of development costs inform decisions on what to develop next.
At Unruly our teams are all working on multiple product streams. We don’t have long-term project or release plans. We deploy features as soon as we can rather than to hit a release date. We agree the next set of priorities with our product stakeholders every few weeks. The team makes a proposal of what seem to be the most valuable stories to work on next and we also offer our stakeholders a list of alternative options as estimated stories. There’s a bit of shuffling in the meeting, which typically takes less that 30 mins. We are not making a commitment to deliver exactly those stories as something more important may come up.
As we whittle down our proposed list of best value stories in the lead-up to story prioritisation with stakeholders, developers make two kinds of estimate. A rough “ballpark” given by a lone developer is used to figure out whether to bin the idea or do further investigation. A “full estimate” is given by the team when the developer investigating that story has gathered enough information to bring a proposal to the team. We only put full estimates on stories that are strong contenders to present to stakeholders for next iteration.
I wonder if #NoEstimates approach is effective when there’s no significant value tradeoff being made around strands of work (sets of small user stories) and that we find estimates useful because we’re looking for the most valuable stories each time and development cost is a part of that. I think it’s because we’re in a #NoProjects context that we find estimates useful, I’d be interested to hear your thoughts on this.
Yes my thinking is similar.
I think estimates can be useful:
- for the team (understanding work, selecting work etc.)
- in the short term (next 2 weeks good, maximum 12 weeks out)
I have a long blog from last year about my thinking, if you don't mind me linking
http://allankelly.blogspot.co.uk/2013/04/to-estimate-or-not-to-estimate-that-is.html
I agree with much of what the #NoEstimates gang says although I feel there is a bit of "throwing the baby out with the bathwater".
The mis-use of estimates (usually beyond the team and far into the future) causes a lot of problems. And sometimes the information conveyed in an "effort estimate" isn't really that useful (particularly if people remember they are *estimates* not promised.)
My standard line for longer range work these days is to: Forward planning should be value not effort based.
So I ask the business to estimate business value before any effort estimates are made. (They can do this using planning poker just like effort estimation.)
If nothing else it gives the business folk a new appreciation of the difficulty in estimating. Developers sometimes find it amusing to here the business folk trot out all the old "I can't estimate because..." lines which the business usually criticise.
Posted by: Allan Kelly | 07 April 2014 at 12:05 PM
I wonder if its that you run #NoProjects or just that you're run by XPers? Most of the companies run by old-school XPers that I know are quite happy with estimates because they understand what they are: educated guesses about an uncertain future. We use estimation to cost external projects and I've found it relatively easy to educate customers on the uncertainty of estimates ... partly I'm sure because there is no-one else in the business they can ask to get a more 'conventional' view.
One of the things that saddens me about #NoEstimates is that it eschews what I think has always been a valuable learning tool. Estimation as a process is one of thinking about and discussing the problem and its solution(s) and getting estimates 'wrong' is a chance for reflection and improvement (whether improvement of estimating or of an environment where even accurate estimates have no bearing on time to deliver). Yes its hard to get good at but that's true of many things:
Kid: I want to learn the guitar and play some gigs
NoEstimates Dad: Playing the guitar is hard. I tried and couldn't do it. Some of my friends tried and they sound awful.
Kid: But if I practice and get good at it I can make people happy
NED: But not many people are good at it, what makes you think you can be any different? And think of how disappointed people will be if they come and listen when you're not very good - they'll just shout at you (or worse).
Kid: I'll just tell them I'm still learning and maybe they'll like my stuff enough to encourage me to get better
NED: there are lots of other ways to entertain people with music. Why not just put a CD on and tell them live music is overrated - full of mistakes and imperfections. They don't really want to listen to live music, they just don't know that yet
Posted by: Pauldyson.wordpress.com | 07 April 2014 at 02:14 PM
From your description, it sounds like you are doing very little estimation, and for the right reason. I don't know your exact circumstances, but I think we are in a similar situation. Except that we maybe produce the estimates not only for the right reasons.
I also see some value in the "estimation process" my team uses (1.5 hours every two weeks, planning poker) - especially the discussions that happen there. And there's maybe even some value in the estimates we produce. But: I think we could get away with less. (Unfortunately, I am the only one who wants to try it).
Our average user story is 2.something story points, and we usually accept stories <= 8 story points for development. So I think we would not lose much precision when we just estimated stories as "small enough for development" / "too big". Then we could move the (valuable) discussions closer to when the work happens - like, right after we start working on it.
So, the real #NoEstimates question for me is: "Could we get away with a lot less than we do now". And the answer to that is probably often "yes". But maybe I didn't understand #NoEstimates correctly.
Posted by: David Tanzer | 08 April 2014 at 08:30 AM
One core element here is that estimates are used as an internal measure and not a target. Many of the destructive effects of estimates come when they are treated as promises.
Posted by: Niklas Björnerstedt | 09 April 2014 at 05:19 PM