Ron Jeffries on #NoEstimates


#1

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?


#2

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.


#3

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.