I’ve been practicing #NoEstimates with my teams for the last 2-3 years if you want to know how it worked for us, read below.
First of all an answer to all the people that in these years have been telling me “Yes, but if you are breaking user stories down, then you are estimating”
Not at all #1: There is a fundamental difference in the the way we think when we are estimating a story and when we are trying to break it down into simpler ones. In the first case we focus on “how big is this?” in the second case we focus on “let me understand this well so that I can identify simpler sub-entities”. The result of the second exercise is improved knowledge, in the first case this is not necessarily the case.
Secondly an answer to the people that in these years have been telling me “Breaking down user stories is dangerous, you will lose track of the big picture”
Not at all #2: We haven’t lost the big picture in 2 and 1/2 years, I am not saying that it is not possible but I would argue that my factual experience on the field is more valid than your hypothetical worry. And on top of that, there are 2 very underrated but positive effects that comes from breaking down user stories into their smallest possible pieces. Number 1 is the fact that we end up with much simpler user stories; less complexity implies less errors hence less rework. Number 2 is that smaller stories mean smaller size/complexity variability hence higher predictability.
Now don’t get me wrong, breaking down user stories is not easy at first. It takes a lot of patience and perseverance, but once you get good at it, you will see that the benefits strongly outweigh the effort.
Finally an answer to the people that kept telling me “Predictability is important, #NoEstimates doesn’t make any sense”
Not at all #3: Believe it or not but if you get good at #NoEstimates, due to the practices used in points “Not at all #1 and #2” above your forecast becomes much more accurate. In fact, points 1 and 2 make your delivery more predictable.
NOTE for scrummers: I can understand the frustration of people trying to do #NoEstimates with points 1 and 2 while doing scrum. If you try to break down a large number of stories the further in the future you go the more you will stumble upon unknowns. I practice lean software development and would break down user stories Just In Time. This allows me to work on the next most important thing only (I don’t need to fill up a sprint) We use the learnings from the stories we have just completed trying to reduce speculating on unknowns that will be discovered later.
So I suggest:
- Delay the break down of user stories at the last responsible moment
- Stop predicting, be predictable
- Have fun!
| Reference: | #NoEstimates a simple experience report from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
When you “breakdown” User Stories you’re following the advice used since the dawn of project management’s construction of the Basis of Estimate. Yes you gain better understanding of the work to be performed and the capabilities asked for by the customer. That “breaking down” also provides you with a statistically narrower variances on the effort to produce the outcomes of the Story. This is standard practices in all mature project work – from construction to manned space flight. To deny that “breaking down” stories is ONLY for understanding, willfully ignore the information produced by that effort, that can be used… Read more »
When you break a user story down, it is no longer a user story. You can call it a chapter, or plot line, but a user story is the big picture.