Uncovering better ways- not just story points
A few weeks back my colleague Dan Prager posted a question on LinkedIn to get some thoughts on teaching teams estimation practices.
"Can you teach beginners to jump straight into fine slicing and a #noestimates approach, or is learning more basic approaches like ideal time estimation or the most common story points / planning poker a necessary apprenticeship?"
I wrote a post a few months back prompted by coaching teams who were seeking to tweak their existing estimation practice. The teams were using story points and were relatively (pun intended) happy but wanted a bit of a refresh (thoughts on this here: https://collectednotes.com/garethlw/story-points-if-you-must
The intent of this post is to answer with some simple practical thoughts on:
My team are struggling with story points- what now?
or
I've started with a brand new team, I don't see value in story points, lets skip that and try something else.
I am skeptical of practices when they become the de-facto way to do things. This can create blindness to better ways of working contextual to your team and organisation. The title of this post starts with "uncovering better ways" from the agile manifesto- that doesn't mean everyone do the same thing the same way that or that there is only one way to do something.
Try this:
The simplest method I've used with a number of teams utilises cycle time & item count as method to forecast forward. That is- agreeing as a team on a way to slice and break down your work down based how long it takes to progress through to "done" on your teams board.
As an example: lets agree to break our work down so that it moves from in progress to done in 2 or 3 days (cycle time). This can form part of your team's working agreement. Using this as a data point, once in place you can look at your team's data to review how many backlog items got to done based on your chosen timescale /your sprint cadence. You can then adjust your slicing practice or agreement accordingly based on what suits the team. Then use this to forecast.
Why is this useful?
When I've looked at many teams' historical data on how they break down work and get things done, I've found consistent themes which help support this way of working, with many teams already consistently breaking work down into fairly even size.
The key advantage of this approach is that by using cycle time, it provides a real measure to reflect on. Its not an abstract number sequence to apply to an already complex type of work.
Break work down, do work, reflect, adjust.
Caveat: if your team and organisation view "story point delivery" or "velocity" as a performance measure there is likely a lot of deeper work to do!