So you are in this agile transformation but, hell, you’ve been doing this for years and things like Story Points just do your head in. Surely by now we have something better?
Maybe. The obvious thing to replace story points is measuring throughput or cycle time. Eventually you can get back to your happy place of #noestimates and simply shipping a new customer request every few days.
We can talk about these later, but let’s reflect on where you are today and what simple and useful options you have in front of you.
Hint: Story points are probably still useful.
The problems you might be facing include;
Uncertainty down the line about when things will be ready and the related struggles managing expectations and downstream processes like marketing
Poor understanding of the requirements from the client/users
A lack of trust from management that your team is focused and doing the right thing
The team are subject to a tech lead who makes all the design decisions
A lack of commitment to the work due to a combination of the above issues
Story points – or more properly planning poker - are actually a useful tool to address most of the above issues.
Planning Poker is a simple idea that everyone can quickly get, so you get mutual understanding and consensus on an approach.
Planning Poker focuses primarily on shared understanding. The story points are simply a signal as to whether the team have shared understanding.
Planning poker is blind-delphi estimating, addressing the boas of following the leader
Planning Poker provides a structured way to challenge and explore requirements in a way that builds teamwork and collaboration with the product owner
Planning Poker focuses on a shared commitment to understanding and executing by the whole team; it enables better task breakdown and planning because the team grok what is needed better.
Over time Planning Poker will let you do regression analysis on stories. It will show you what normal story sizes look like, and the variation around them.
Story points get people away from estimating to what product owners hope to hear because they are focusing on the job to be done – understanding the story, and particular investigating it’s inherent uncertainty
You can reverse engineer story points into time estimates, over time; i.e. after you have a reasonable data set for your team
If you skip growing this capability, you’ll face other challenges;
When you start estimating you don’t have historical data to work with so you probably won’t be reliable.
You’ll keep using dates and you won’t get your opportunity to wean people off specific due dates
Planning Poker’s investigation discussions need to be had. If you don’t build the pattern of conversations, you’ll never build that skill of groking the requirements.
You’ll follow the tech leads estimates and fail to grow that skill in others, subjecting the team to a dependency on the tech lead’s design as well. This will further limit opportunity for growth in other team mates, as well as potentially keep usually silent but experienced voices out of the planning process.
Planning poker can gamify improving. You have a score, and you as a team work to improve your score over time. This is harder of you are always chasing deadlines or throughput targets.
Through using Planning Poker you’ll learn what a normal or standard sized story is for your team. Basically you defer growing the skill of story slicing until you master the skill of challenging and understanding the stories.
When learning to slice down to small stories, Story Points provide a good guide to your improvements, independent of environmental factors like wait times on other teams.
Once you can reliable achieve the following things, you should move beyond story points onto a more reliable estimate process like measuring throughput or cycle times, or you could potentially abandon size or duration estimates altogether. As long as you keep challenging the stories to understand what they will take, what assumptions are embedded in them and what uncertainties they hold.