In a recent blog post by Mike Cohn, he wrote about Establishing a Common Baseline for Story Points. He explores the technique of getting estimators in a room from many teams. Perhaps a pair of individuals per team.
The entire room uses Planning Poker to estimate stories. The focus is on getting all of the folks in the same ballpark when it comes to estimating their stories level of effort.
The idea is not to have everyone become a clone of each other. But to get the story points close enough so that forecasting can be done across the teams. So, consistency without normalization or fixed rules.
Not only do I like this approach, but I’ve also successfully used it with several companies where I’ve coached. Not as an external coach, but as an internal coach. And it works quite well.
The Notion of Reference Stories
I’ve used another tool to help inspire consistency and it’s the notion of a Reference Story.
A reference story is a user story that is mined from our existing product backlogs. It’s been implemented and delivered in a sprint. It had an original story point estimate. One that was qualified to be relatively accurate/good/representative by actually delivering the story.
For example, a 3-point story was estimated as a 3 and, after delivery, everyone on the team agreed that it was actually a solid 3-point story.
That story could become a reference story for future estimates. A reference story is an example, a model, or a surrogate, or a proxy, or a persona for “the perfect 3”.
It helps teams to visualize each of the story point levels that they’re typically estimating in.
One of the reasons I like minimal story point options (for example T-shirt sizes over Fibonacci) is the reduced number of choices – leading to a reduced (malleable) number of reference stories.
I’ve used the term reference stories before in this post –
http://rgalen.com/agile-training-news/2015/4/6/the-collective-memory-of-the-team
Technology Stack Implications
And of course, there are stack implications. Meaning, you might have…
Mostly front-end centric reference stories
Mostly back-end centric reference stories
Architecturally focused reference stories
DevOps focused reference stories
UX design reference stories
You get the idea. But please don’t create too many of them. They lose their effectiveness and simplicity if you have tens of them posted all over the walls.
Danger Will Robinson
But back to Mike’s post…
In a follow-up article, he cautioned folks against some dangers in using the recommendations from the A Common Baseline article.
Here’s what he said -
So, should you establish a common baseline? Yes, if there are advantages to doing so on your project. If you do, however, you need to make sure you go out of your way to create safety around that baseline for the teams. Stress that this isn't being done as a way to compare teams and that you (and your bosses know) that there are many factors that influence velocity, not just "how good" a team.
Wrapping Up
I think there’s a fine balancing act to be struck here in order for this to work. And Mike clearly alludes to that across his two articles.
If we create too much flexibility, then forecasting across multiple teams can be almost impossible. Which is a problem if the teams are working on the same product.
However, if we apply too much restraint, such as SAFe does with their forced normalized story point estimates, then we lose the inherent team-based uniqueness that story point estimation affirms. It also undermines or eliminates the wonderful value in the conversations surrounding story point estimation.
It’s a conundrum if you will. With a choice to be made. I lean towards the collaborative baselining approach that Mike describes. But you may lean in another direction. But in either case, please consider Reference Stories as a means of reducing the variability in your point estimates.
Stay agile my friends,
Bob.