3, 5, 8
Similar experience, but w powers of two.
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!).
Would you agree?
[quote=“hdietrich, post:13, topic:1132”] the need for estimation is an indicator for the maturity of teams.
[/quote]
Could very well be true… how could one get some data to explore that hypothesis?
I have an article mentioning the study on my mind as well, but I do not know where to find it anymore. Does anyone have a link?
Ah, google, dear google, where would we be w/o ye.
Slide show from Agile2017: https://submissions.agilealliance.org/attachments/3590
Abridged version w only the slides with reference sources:
The NoEstimates Movement - Agile 2017.pdf (243.9 KB)
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
http://www.toddlittleweb.com/Papers/Estimates%20or%20NoEstimates%20IEEE%202016-01-22a.pdf
Thanks for you support!
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:
http://www.toddlittleweb.com/Papers/Estimates%20or%20NoEstimates%20IEEE%202016-01-22a.pdf
Wow, very cool! That’s almost exactly the path I’ve accidentally discovered.
Thanks for sharing @andycleff!
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.
RE: limit the size of stories
The team I’m currently SMing I told them “No more 8s!” which a sprint or two later became “No more 5s!” which is now becoming “No more 3s!”. I realize this isn’t realistic for everyone but it’s really helped the team mature; their velocity is steadily improving, they predictably deliver on what they commit to, and we’re pulling work in by the handful.
We do however estimate tasks; the team told me that they prefer to do this because it forces them to think even more granular. During grooming I’m seeing more and more instances of “what about task x, y, and z?” and then “this is too big, let’s split it up”…coaching themselves. It’s a beautiful thing!
Perfect timing: Stay tuned for an upcoming podcast on Dynamic Reteaming w Heidi Helfand!
Sneak preview:
Heidi Helfand - Dynamic Reteaming https://leanpub.com/dynamicreteaming
Another way I like to think about the question of “to estimate or not to estimate” is what is the opportunity cost of the effort spent estimating. In other words, what else could you do with the time you spend estimating?
You could use that time to estimate the value to help prioritize the team’s work.
You could use that time to identify 2-3x divergent ways of approaching the same problem, finding approaches that are cheaper or that can be tried if the first approach doesn’t work.
That said, it is important for work to be roughly similar in size to abandon estimates, which takes time as a team gets familiar with each other. And it’s still important for team members to have a way to identify work that is too big, too ambiguous, etc - perhaps a hand signal that any team member can quickly throw - similar to planning poker. Therefore, for a new team, estimating might make a lot of sense. As the team matures, abandoning estimates may also make a lot of sense, using that time for more valuable things.
There’s a quick read about creating multiple user stories for each experiment at http://www.howtotrainaproductmanager.com/how-to-set-your-team-up-for-failure/. Interesting way of thinking to generate more approaches and make room for failure / pivoting.
This is very similar as to what we are doing as trying to move away from time estimation. We use also 1, 3, 5 but also 8. The point basically translate directly to complexity as simple, medium, complex and finally highly conplex. I like to have the possibility to Give an 8 as they have been actually a really good discussion opener for us. It often end up telling that either the story is too big or the story is not clear.
We use a question mark for the same purpose as your eight. It is too big/complex it gets split again or marked as not ready. It works for us.