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:
1) Delay the break down of user stories at the last responsible moment
2) Stop predicting, be predictable
3) Have fun!
mysoftwarequality 
Hi! Nice post. Yes I also love the idea of breaking things down and do it as late as possible.
But even if you break things down there will be variance, right? Not everything takes an equal amount of time. Because ideas don’t come in equal sized boxes.
My point: whatever we say and however we come up with an idea about the size of something: it’s an estimate. Because we don’t *know* and we don’t *guess*. Thus, even “breaking things down” is in the end an estimate.
But anyway, nice approach!
I agree that variability cannot be eliminated completely, but if you don’t break down stories you expose yourself to higher variability, so the focus on identifying the smallest possible story, reduces variability, would you agree?
In a way I agree. But not my point. Customers or stakeholders are mainly interested in their idea they had or the capability they want/need. And those ideas are what really matters in the end. And those ideas/capabilities don’t come in predefined sized boxes. So even if you break things down, there will be variance in the “big picture”. And that’s the estimate that really matters. Your customers don’t really care how much you break things down.
Also, breaking an entire idea/capability down to smallest pieces sounds like BDUF (aka “waterfall”).
But, yes, the idea of breaking things down is wonderful. I do it all the time. But it doesn’t eliminate the estimate that matters most: “When can I expect to have this idea I have to be ready for use, and what will it cost me?” *How* you answer that doesn’t really matter that much.
I might have violated the laws of mathematics, physics and planets movement and for this I apologise profusely. You might have missed the point of the post violating the rule of reading the content before replying, but that’s fine with me.
[…] #NoEstimates a simple experience report Written by: Augusto Evangelisti […]
[…] create controversy. Well this normal person is wrong. A couple of weeks back I shared a report on #NoEstimates based on my adoption experience in the last 2-3 […]