I’ve been reading a lot lately about “not estimating stories in Agile…” or “why you should stop estimating all together.” – To be frank, I’m not quite convinced, holistically. I believe that there is significant value in estimating at some level, just not spending too much time doing it.
Accuracy over Effort
In my depiction of accuracy over effort here I say that find a healthy balance between just enough time, and getting some estimation done. Now, some would say: “The trick is to consistently estimate over time…” Maybe it’s more like: “Consistently estimate wrong.”
Michael Dubakov tells us 5 Reasons why we should stop estimating:
- You don’t waste time on estimation – It is waste of time.
- You shouldn’t explain to higher managers why it took so long – Focusing more on explaining the problems than measuring against an estimate… and you don’t need to explain anything more than just how you can resolve the issues.
- You don’t give promises that are hard to keep – People don’t believe your estimates anyways. Better not be accountable lest you have to explain yourself.
- You don’t put additional pressure on development team – Estimates = A deadline. You wouldn’t want that would you?
- You focus on really important things – Epic or not, size or not. Doesn’t matter. By not estimating you can focus on… whatever is most important (according to the Product Owner).
Cory Foy tells us that story points are dead and that in reality…
Cycle time (Kanban metric) is far better with a filter of Classes of Service (David J. Anderson concept):
- Rather than add up the story points completed during the sprint, they measure the cycle time of the stories. The Cycle Time is the amount of time that it takes for a story to go from initially being worked on through shipped.
- Classes of service are a recognition that all work is not the same, and should likely not be treated the same.
- What does this all mean? – Rather than estimate points, follow story completion from beginning to end and give yourself some slack in regards to types of stories. This will, hopefully help you better track and forecast out release times.
Mike Cottmeyer tells us that we may be looking at estimating all wrong…
We really should be (maybe) using estimation as a way to cut out pieces of unnecessary work:
- I find myself using estimation to help teams figure out what we are NOT going to build. Rather than create an IN list… I like to think about creating an OUT list.
- Ever though about using estimation as a way of committing to what we AREN’T going to do?
- So what does this all mean? – Maybe we should look at estimation as a way to filter out that which provides little value. Focus on the 1’s and 2’s.
So what next? Is Agile estimation dead? Where do we go from here?