Recently I dropped a tweet in Twitter with a bit provocative statement about errors in estimates and added the hashtag #noestimates. I would have never thought that this would drag me into such a harsch discussion about estimates and commitments.
While I have had interesting and even good results from setups without estimates, I would not claim that estimates can be left away under any circumstances, nor would I claim that they need to be present to be able to deliver. For me they are a tool for creating an idea of future activities and outcomes. But it is by far not the only one.
Anyhow, there seems to be a kind of religious war between estimators and noestimaters. Ones are pretending business will not be possible without estimates and commitments and noestimators will put whole organizations at risk, while others pretend that estimates are used to force commitment and delivery under every circumstances,which would be a form of modern slavery.
I am wondering thereby if I am just naive or if there is some common sense about estimates I am missing out. What is your experience with this topic, independant if you are an estimator or nonestimator or inbetween?
The debate on Twitter is now 99% devoid of any value. It’s unfortunate because as a pragmatist, it’s easy to see how simple it is. When you need to estimate, estimate. When you no longer find it’s helpful, stop doing it. If you try not doing it and things stop working, ask why, investigate, and decide on a new experiment to try.
FWIW, I’ve only ever muted 2 people on twitter, and they are both from the “YOU NEED TO ESTIMATE THINGS, YOU IDIOT” camp.
I mostly stay out of the discussion now, other than to throw in the occasional semi-troll statement
I didn’t understand the whole #noestimates movement until I read the book, and then it made perfect sense. I feel that everyone arguing on Twitter is fighting about semantics; what I took from the book was “Don’t make estimates, build forecasts. Small package size helps ensure your forecasts are accurate (at least with less deviation than an upfront estimate).” I grossly oversimplified Vasco’s work but that’s my gist…and it makes PERFECT sense, even to a PM like me. Some people just want to argue…and it always seems like it’s the same 2 or 3 people starting it.
Well, if I want to have some attention at Twitter I take exactly this statement and post it with the hashtag #noestimates. That’s exactly that kind of religious war I talk about.
I guess you need to experience #NoEstimates before it makes sense to you.
I for myself realized that the estimates of a team became 3, 5, or 8 story points without really affecting the planning. The velocity was in a range, where it did not really matter if more stories were estimated with 3 or with 8 story points. It was the number of items, which showed if the team was motivated and engaged or if the team was looking for some recess for consolidation. So in this case the team did an indirect decision for #NoEstimates that I had to follow
After a dozen iterations, doing an rolling average of 100 issues and 800 points, we called everything an 8.
During grooming only time we diverged from that pattern was if team felt it was bigger (risk, complexity, effort) than average, at which time we discussed splitting.
“Planning poker” became unnecessary, bulk edit our friend, and the suits stayed happy enough to leave team alone…
Our friend Ryan Ripley mentioned a study he found in relation to no estimates. A company went through it’s traditionally scored backlog and resized everything to 1. When they measured the difference there was only a 3 percent variance on the points. I found that very telling.
It was IBM, I can’t remember the division. Well worth the listen. I’m going through it again. We went the 1, 3, 5 route and it has really opened the communication between the team and PO. So, for me, that is a win.
Some random thoughts (can’t carve out the time to watch the video now…)
1 - What’s the -pardon the wordplay - point of estimation? If it’s strictly for the team to structure their backlog and plan their sprints, then maybe estimation is a no-harm no-foul thing. That said, maybe there’s a huge time sink in doing the estimation. If it’s for bigger planning by the enterprise across multiple teams then, IMO, estimation gets confusing, watered down and less meaningful.
Across several teams in different companies, @hdietrich and @andycleff’s experiences line up with mine. Might as well call it “Rock-Scissors-Paper”… Challenging one of my teams to experiment, I proposed that they give up sizing, assuming a standard “point value” for all stories and going for that bigger or smaller idea that Andy mentions. , They didn’t opt for it… I’ll point out that I wasn’t suggesting that they not have refinement sessions on the backlog - lot’s of insight comes forward, but that team is attached to their point values.
2 - Going back to estimates for bigger planning, I personally find throughput, cycle times and confidence levels better indicators for larger predictors of delivery.
Listening to you, the idea pops to my mind, that the need for estimation is an indicator for the maturity of teams.
The longer an agile team works together and the more experienced a team becomes, the better the team will know which size of stories they can handle best to have a good balance between outcome and risks. By then deviations from disruptions, uncertainties, and unforeseen limitations are averaged out and throughput becomes the primary measure.
Young, inexperienced teams so far will use estimates to learn more about the quality of their work and how to handle it better. Improvements will get addressed by user stories and procedures, which become more robust.
While with a less experienced team the manager will have to break down projects into stories and asks the team to estimate (well knowing that he needs to add some buffer), he will ask a more experienced team only for the number of stories they assume it will required to implement a specific project and the throughput for planning (which is team empowerment!).
His path:
1.IF YOU ESTIMATE IN HOURS MOVE TO SP’s
2.DON’T ESTIMATE TASKS
3.LIMIT THE SIZE OF STORIES
4.IF YOU USE SP’s, ONLY USE 1,3, and 5
5.BUILD CUMULATIVE FLOW DIAGRAMS
6.EVERY STORY CAN BE A 1
7.NEGOTIATE DECISIONS, NOT ESTIMATES
@andycleff Thanks for sharing. It got me in the right direction now.
BTW. there has been another person who told me about the Google thingy a while ago - feels like I should give it a look next time
I was probably not as precise as necessary in my request, but I have been searching for some “figures” from a study like the following one, which was not that easy to find for me
That link is broken for me because it got rendered with extra escaping (the %20’s got replaced with %2520). I fixed it manually, so let’s see if it works when I paste it back in:
I agree - one measure of maturity for an Agile team is whether/how they estimate. The highest-performing teams I’ve worked with “size” all stories about the same (can be completed in under a day) and they plan based on number of stories. Our cycle time goal was to get all stories through from dev to deployed in Prod in 1 day (6 hands-on hours) or less. At that point, there’s really no need for sprintly planning either, it becomes an artificial date that slows the team down since they’re having current and future-looking story conversations together every day throughout the day - those teams just discussed what they were going to accomplish for the day during stand up and that essentially became planning too. The PO just kept the backlog ready at all times and the team discussed upcoming stories with the PO daily. We still kept the retro and review on a sprintly cadence, but the rest morphed into something closer to Kanban. (Incidentally, we called ourselves Scrumban teams because we held onto the ceremonies but focused on minimizing WIP and optimizing continuous flow.) Of course, there are several other mature practices a team will have to adopt and have mastered to be able to flow at this level, including a heavy emphasis on Lean UX, DevOps or NoOps, and BDD.
I wish all teams could get to experience this - it’s exciting and fun to be part of a team that produces great value, quickly and consistently, and where you really get to see how easy and fun Agile can be. I’m working on a theory/experiment about doing something like an “exchange student” kind of model where folks who are new to Agile/on new Agile teams leave their teams to visit and work on a high-performing Agile team for a certain length of time to get hands-on experience with the tools and practices the team is using so they really see and understand how the work should flow, and then they would bring that learning back to their teams to accelerate their growth - leveraging a learn-by-doing model.
