#NoEstimates, forecasting with minimal estimating
Jan-Willem Rutten
De Workshopper: training and workshop design ? facilitation ? team coaching ? liberating agility for better results with more fun!【ツ】
Most development teams still forecast their work through story point or time estimation, which can be a time-consuming process that delivers little value when you think about it.
#NoEstimates states that estimation of complex work is a form of waste, as every estimate is actually a guess due to the many unknowns. Instead of doing forecasts based on estimated items, it advocates for forecasting by COUNTING items. Sounds interesting, right? Certainly if you realize that humans are pretty good at counting things and absolutely rubbish at estimating things.
There are several ways to approach this way of forecasting in your team. This article briefly explains three of them. If you have other examples, please add them in the comments.
Everything is 42
With this approach, which is most common, estimates are based on a reference item with the right size, which in this example is 42 (see my LinkedIn article about the theory behind the Enexis estimation card game). If an item is not 42, it has to be made smaller, larger, simpler, or more extensive, until everyone agrees it is of the right size. This way the team ensures that all items are approximately the same size, which makes forecasting a lot easier as they know how many items they can realize within a certain timebox.
One acceptance test
Another way is to split up the work item into smaller items that only need one acceptance test each. Because in this process, you divide a work item into different functionalities, the side effect is that you can easily cut away functionalities that add little value. You will save some time that is better spent on more important matters.
领英推荐
Too F*ing Big
With this approach each team member has three choices when doing Planning poker:
That’s it! Both simple and powerful. 'TFB' fits perfectly into a flow-oriented approach such as Kanban. If the "1" is larger than a day, it would probably not work within time-boxing frameworks such as Scrum. The "1" might represent a couple of hours up to a full sprint, so it would be difficult to guess how many items a team could handle within an iteration.
?? To wrap up the subject of #NoEstimates, here’s a quote from Ron Jeffries, the creator of Story Points:
Some people are tempted at this point to say that this right-sizing is a kind of estimation and therefore we aren’t eliminating estimation after all, hahaha therefore you #NoEstimates guys are full of it. Yes, well, most of us would be happy to be full of it if you’d all start using this kind of estimation instead of the kind where you try to force us to put a number on whatever vague notion of a feature you have mumbled about, and then you add up the numbers and then you tell us that the numbers are too large and the real numbers are these ones that you made up, and then you demand that we make reality match your numbers, while at the same time you’re changing the things you mumble, adding new mumbled things, and shouting that when you mumbled something that sounded like “purple” you clearly couldn’t have meant “purple” and what is wrong with us can’t we work with perfectly clear requirements and by the way why aren’t we done yet, scurvy scum that we are.
?? More information on estimation, and a ready-to-use workshop, can be found in my latest LinkedIn articles. Check them out and share your own approaches and experiences in the comments. Looking forward to learn more on this subject!
I have always struggled a bit with the NoEstimates concept. Especially the bit where you should count items thatvare roughly the same size. Determining whether they are roughly the same size is also an estimation. The statement that estimating is waste and should therefore be eliminated also feels uncomfortable. Not all waste can be eliminated, there is also necessary waste. When there is complexity in the game, waste will inevitably occur. It's the price in efficiency, with the gain of effectiveness. And is estimation really 100% waste? If you never wonder "hmmm... how expensive would this feature be?", then how do you determine whether to invest in it? Also, the stakeholders need some kind of idea when they can roughly expect to receive the feature. This allows them to plan marketing, training, support, etc. This is also value. So mybstatement is that estimation is not 100% waste. So minimize estimation, don't try to eliminate. Estimating every task by discussing them in detail is over the top. Instead, estimate slightly larger compound items using an efficient technique. Planning poker is not the only way, experiment with techniques like magic estimation. It is possible to estimate an entire backlog in a few hours max
De Workshopper: training and workshop design ? facilitation ? team coaching ? liberating agility for better results with more fun!【ツ】
10 个月I'm re-sharing this comment directly under the article, as Rob Eijgelshoven made an interesting remark: Counting items offers just as much (if not more) accuracy as using Story points to determine velocity. I have seen the same thing with some of my teams. We had larger items as well as smaller items in the sprint, so the #NoEstimates principle did not apply here. Is there any scientific source availabile to back this up? This could confirm that, after using estimation to create a shared understanding of the work, it isn't necessary to record a final estimation number, as you can just as well base your forecast on the number of items that the team is likely able to finish within a timebox. In that case you could even take it one step further, and move on to probablistic forecasting using Monte Carlo simulation. I will post on that next week. ??
Experienced Manager and Agile Coach | Expert in Leading Cross-Functional Teams and Enhancing Processes
10 个月Hallo Jan-Willem, Interessante punten die je aanhaalt in je post. Ik sluit me aan bij Bob Kosse wat betreft het doel van 'estimation'. Echter, als we kijken naar de hoeveelheid werk die we per sprint kunnen opnemen (velocity), heb ik gemerkt dat het tellen van het aantal user stories een even betrouwbare indicator kan zijn als het aantal story points. Een paar jaar geleden heb ik voor twee teams statistieken bijgehouden over een periode van ongeveer twee jaar. Uit die gegevens bleek dat het aantal user stories in een sprint een net zo accurate, en soms zelfs betere, voorspelling gaf van de hoeveelheid werk die opgeleverd zou worden. Zijn er anderen die vergelijkbare ervaringen hebben of andere methodes gebruiken voor hun sprint planning?"
Meer resultaat, minder gedoe in het mkb. Ik help je binnen 3 maanden naar productievere teams
10 个月Hmm, I always thought the Story Point principle was to align the team about the story. So it is not actually the points that matter, but the difference in the estimates. For me the crucial question during refinement is: “Why do you think it’s X amount of points?” In the end, all team members should have the same understanding of what is involved with a particular story, showed by the same estimates. A side effect (or maybe benefit) is the option that we are able to do forecasting and Sprint Planning based on those estimates. Of course I know that a lot of teams struggle with their estimates. I hear a lot of “I was doubting between 5 and 8, but I can live with a 5.” In that case, most estimates are wast of time. I always want to know why you were doubting. Other team members might doubt between the same numbers, and after hearing your concerns, they maybe estimate for 8 instead of 5! To go for short: I don’t think the process or idea behind estimating in Story Points is bad, in most cases it is the understanding and execution that causes the problems.
De Workshopper: training and workshop design ? facilitation ? team coaching ? liberating agility for better results with more fun!【ツ】
10 个月Addtional resources: ?The theory behind the Enexis estimation card game: https://www.dhirubhai.net/pulse/theory-behind-enexis-estimation-card-game-jan-willem-rutten-eshoe/ ?The workshop: Explore new ways of estimating work with a team: https://www.dhirubhai.net/pulse/how-explore-new-ways-estimating-work-team-jan-willem-rutten-snf7e/ ?Source of the Ron Jeffries quote: https://ronjeffries.com/articles/015-jul/slicing/