#NoEstimates – simplicity first

WHY #NoEstimates instead of using story points or detailed time estimations? … Please check the great input by the #NoEstimates movement and the great new book on #NoEstimates by Vasco Duarte
. 
This post is a short summary how I introduced it. Just use it as a shortcut for your next step.
To roughly categorize a work item’s (story, task) size I use T-shirt sizes S (around 2 team days), M (around a team week), L (more).

In the team we use a hand sign (1=S, 2=M, 3=L) as a first indication, whether there is a different understanding off the topic. 

Followed by a short discussion, to clarify why team members maybe differ and another round to check for the final size. It’s a kind of the Planning Poker®, but we don’t need cards for that and it’s simpler as the choices are much more limited. 
L – leads to a splitting of the work items in smaller items. S,M work items are eligible candidates for the iteration (sprint).

Having the decision that a story is of an appropriate size is enough. We don’t use the sizing information any longer.

Use cycle time and a scatterplot diagram for visualizing your story completion statistics. You can spot outliers, discuss about possible reasons and ways to change your process. Using these metrics I can see what date range to expect for a story. (stay tuned with my next blog post describing my insight about core agile metrics for predictability).  

Velocity is based on the number of work items we finish in an iteration. Just that simple.
For release planning you need to have an overall rough “estimation”. If you have epics in your backlog just ask roughly how many stories that epic will consist of. This way you can use the number of stories and your velocity for release planning too.

We just applied the counting of stories in our user story map too. Epics in the story map are marked with the number of stories (later on epics are split). This way you can have a fast overview and check when a release will be done.

To introduce it I highly recommend using an experimental frame. Provide a time range for trying this approach and define your hypothesis and measurements to check whether it’s working for you or not.

This way you very likely have a buy in and people are willing to try it out.  

Just today I joined a great Meetup where we discussed about #NoEstimates

It was a great discussion and I guess there’s an evolving understanding why the traditional way of estimation is a wasteful activity and just leads to false security and assumptions.

Tweet: Stories need to be accessed for their fitness for purpose, NOT estimated
Stories need to be accessed for their fitness for purpose, NOT estimated

Tweet: The goal is to become predictable and efficient, NOT to hit individual estimatesThe goal is to become predictable and efficient, NOT to hit individual estimates

 

References

What’s your next step? Will you use #NoEstimates and if not – why do you continue using estimations?