Ron Jeffries on #NoEstimates


I find there to be something appealing about No Estimates, and Ron lays down someinteresting thoughts.

I worked with one team who had a whole schema set up. After lengthy discussion of the story, they’d pull up their reference spreadsheet, fiddle with numbers for ‘testing effort’, tribal knowledge’, ‘external dependency’ etc. Half-hour later, they’d come to consensus with the point value I had in my head simply based on a count of the number of acceptance criteria. So I get what Ron means by waste. I tried advocating for getting stories to a more ‘universal size’ but wasn’t able to get traction.

I’m also reminded of another team at that org. The team wasn’t comfortable with actual point values, so the Scrum Master had them using T-shirt sizing. He told me they got to the point (pun intended, I guess) where they’d say “This is a Medium… So that’s a 3, right…?”

Closing comment - I often feel that velocity turns into a bigger forecasting tool, instead of ‘next sprint planning’. (Possibly rhetorical question:) Why isn’t lead/cycle time used more widely for projections? Does the Coalition have any success stories here?


I wrote recently in another thread about my success using card counting for forecasting.

As an update:
One of the teams running in this way has recently had a new QA join. After a few weeks we chatted with him and he was concerned that things weren’t being discussed enough with him. We questioned him some more on this as he’s quiet in our daily grooming sessions and changes his estimate to the team’s average quickly. It turned out that he’s used to grooming being a way for people to tell him what to do and had been expected to fall in line with the dev’s estimate. We explained to him that we use points to uncover the lack of cohesive understanding and agreement in the team, so it is important that he stands by his scoring and use it as an explanation of how he views a story. We also talked to him about why we groom every day and what our expectations of him are (asking questions, explaining QA viewpoint, etc.). This taught us that we needed to update our induction so that we better communicate how agile we really are, and how autonomous we expect / require our teams to be.


I think lead/cycle time are one of those things that actually require people to pay attention and understand, like cumulative flow diagrams. Velocity is the “easy” metric, which is why it’s so prevalent in “agile metrics.” At my current gig I tried educating people around how to read/use a CFD and after a bit it took root and now it seems like it’s used more and more, which is so rewarding.

As for the No Estimates movement, I read Vasco’s book and started to use some of his suggested practices, mainly the “no X size stories” and then keep cutting till it’s only 1’s and 2’s…and the benefit to that simple change was mindblowing. The team started to really get predictable, and they became militant around breaking the work into smaller pieces. It was a sight to behold. Sadly, I left the team and the new SM hasn’t been as aggressive with this practice and they’ve had some slippage, but at least they know they CAN do it, and that’s been their motivator to get back to where they were.


I prefer Kanban, and for cards to live at most 3 days cycle time, no gaming with oversliced backlog items. Works to get card count as predictor. Need to also knowstats on card refinement… do on average a card before grooming/refinement becomes 3 cards refined to last under 3 days. Also need rate of cards in backlog not ever being done by choice. So some disappear, some split, some get aborted, and the rest get to done. Now we can make some predictions that are ok 3 months out or less.


Love it @Paul_Elia! I had just configured my team’s JIRA board to have filter for tickets at 4+ Days In Progress. The intent is to be able to highlight those items that may be blocked or stalled. Too long to get into, but there are lot of constraints around this team.

Out of curiosity, do you have classes of service / SLAs for cardflow?


In my current situation, we do use Class of Service = Expedite, Intangible, and Normal, but we do not publish any SLA/SLE predictions at the moment. We converse with each requester early and set expectations in some way though. Our team and our service offerings are just too new and we have yet to hit normal or hit the levels of automation we are striving to achieve. In past lives and in general I prefer Service Level Expectation when it is between two internal teams versus Agreement. All kinds of gaming comes into play when it’s an A versus an E. I see tickets closed under a technicality versus cooperation on the intent and overall goals, sometimes at the very last moment so as to delay the ticket’s return, just to keep individual ticket type SLA statistics looking good on the surface. Damn statistics. The overall system goals need to rule, not segment SLAs; that would be local optimization. Takes a spirit of purpose and greater good to do all of this, granted.