From Story Points to Slam Dunks — Planning for Success

The use of Story Points is riddled with misconceptions and misinterpretations, and many teams are dragged into lengthy conversations on how to make them work for the team and the organisation towards a win-win situation. In this article I will share an alternative method for work estimates that can mitigate some of the problems encountered with the usage of Story Points.

When going for planning or for a backlog refinement of some sort, there is an unmistakable pattern in many teams. Discussions hit a wall the moment someone throws the “E” word: “shall we estimate?” “How shall we estimate now that we’re starting to use Agile?”, and from then on the conversation stops being about the work and, instead, starts focusing more and more on this blessed estimation thing.

Many times I have been welcomed by teams with the seemingly fundamental question apparently any Agile Coach should be able to answer: “Do you suggest we estimate in days, or do you prefer Story Points?” Sneaking behind that question I smell generations of old arguments between the different factions of the team, all holding their fingers crossed tightly for me to give the win to one side or the other.

I have learned my lessons to brush off such questions because when it comes to estimates it is not my preference that counts. What counts is what works best for the team.

That is the core of my philosophy on the topic. The following paragraphs describe my approaches in practice.

When expectations for estimates are rooted in accuracy, I am afraid people are in for wasting efforts and time and exposed to huge disappointment. Estimates are over-rated when it comes to accuracy, because they are not meant to be accurate. They are, as the word goes, estimates (literally “power of approximation”).

Estimates are useful when they are used as means of communication, and the message is about confidence of delivery. Even when higher management engage their most skilled technical wizards to “provide more accurate estimates”, what they are technically doing is that they are bringing in someone who has more knowledge on the intricacies of the topic so that they can shed more light for, guess what, more confidence on delivery.

When teams or organisations claim their need for estimates, it is often confidence on the ability to deliver a work item within a stipulated time frame that is being sought. Be it a project within a deadline, a story within a Sprint, a ticket within an SLA (or SLE): it’s always a quest for confidence. While expertise helps, complex work leaves the doors open for surprises.

That is why all the many theories, formulas and alchemy that promise anything more than confidence are practically missing the purpose.

In Agile approaches the trend to steer away from time-based estimates is rooted in this same argument. So Agile practitioners often propose different approaches that are aimed to condition those estimating to focus on what matters most.

One of the most popular approaches is relative estimation techniques, of which Story Points is a perfect example. The aim behind Story Points was precisely to simplify the flow of communication. It was clear that when software developers were trying to estimate in days the whole exercise was very stressful at best, often resulting in either sandbagging or over optimistic estimates due to the fear that the “quest for confidence” either becomes a hard deadline or a test of competency. That is why instead of days, hours or months we now have a sequence of exponentially growing numbers, typically the Fibonacci sequence, which teams can use to project a size of “complexity”.

But things start loosening up as soon as people try to interpret the Fibonacci scoring to their own understanding of complexity. For this system to work, teams need to identify an anchor: a rule or a work item they can relate any subsequent estimate (hence, relative estimation) in order to score the backlog as homogeneous as possible. Here is a hypothetical conversation (based from experience in different teams):

“let’s take 1 as a 1 liner”…

“let’s take 3 as a typical piece of work that does not take more than 2 days”…

“would it be 2 days with or without testing?”…

“2 days applying our Definition of Done” (note to reader: this step in the conversation is highly optimistic)…

“Ok. So better 3 days for 3 points”...

Until someone says:

“let’s use 1 for 1 day, 2 for 2 days, 3 for 3 days, …”

and voila, the system has gone bust.

Talking about what counts most

I have proposed and used Story Points with several different teams in my experience, I have seen them work successfully and I have seen them fail. I have nothing against the method. I do see, however, two particular shortcomings in Story Points:

1. The method is heavily tied to numbers for scoring, and numbers mean different things to different people. Not everyone appreciates the properties that make the Fibonacci sequence useful in estimating, and unfortunately this may limit the benefits of the pattern to simplistic usage of numbers. There is nothing wrong with using the Fibonacci sequence or any other numerical sequence. I like numbers too. But remember that the bottom line of estimates is to trigger actionable conversations about confidence on work items. There are flavours of the same method that use animals of relatively exponential different sizes (“is this a mouse, a dog, a lion or a giraffe?”) or methods of transportation or other non-numeric sequences, which is good, but then there is my second point…
2. The method asks its users to judge work item on their complexity, and “complexity” is a heavy word. Even worse, the method requires that people can come to terms with it quickly. If you do your research you can find frameworks (like this, and this) that help by giving some pointers or parameters to break down “complexity” into some kind of objective compound variable, but this is still not straightforward. Many, however, tend to interpret “complexity” as “size”, which risks at backtracking all the efforts go to reasoning in absolute time (the total opposite of relative estimating).

With those two points in mind, I empathize why teams, Scrum Masters and organisations take shortcuts when using Story Points when this becomes too difficult to apply.

We need a method that forces those estimating to put on the table what really matters when it comes to evaluating a work item: confidence. Good news, relative estimation is not the only alternative to absolute estimates. Literature presents another method called Commitment-Driven Iteration Planning.

In essence, instead of asking for Story Points, commitment-driven methods leverage the power of iterations and invite those estimating to answer the following question: “What is your confidence in delivering this work item by this date?”.

We stop talking about sizing, and we start talking about possibility, which requires a mindset shift. To make this easier for the teams to engage with, I have started asking the following question instead:

If we were playing basketball, and this work item would be a shot, what are the odds of it being a Slam Dunk?

What is a Slam Dunk?

Photo by Leo Foureaux on Unsplash

Wikipedia defines the term slam dunk as follows:

A slam dunk, also simply known as dunk, is a type of basketball shot that is performed when a player jumps in the air, controls the ball above the horizontal plane of the rim, and scores by shoving the ball directly through the basket with one or both hands.

I like basketball, though I’m not its biggest fan and so I built the connection between the sport and estimating when I encountered the term in Philip Tetlock’s and Dan Gardner’s book “Superforecasting: The Art and Science of Prediction”. With the ball in one hand, and the hoop in the other, a basketball player has practically no chance of failing the shot. That is why in probabilistic terms the term Slam Dunk is often used for statements that project full certainty: 100% probability of happening.

Back to the discourse on confidence, therefore, I use the term Slam Dunk to exclude any whiff of doubt (typically brought by dependencies or unknowns).

Application of Slam Dunks to Estimates

With the explanation of the term Slam Dunk clear, the next challenge would be to capture the gaps in the team members’ confidence so as to provoke the right discussions. Apart from Slam Dunk our daily vocabulary is very rich of terms rooted in the realm of probability. If you want to calibrate your understanding of the different probabilistic terms widely (and wildly) used in our language, give this survey a go.

In my approach, to help these conversations, I present 4 confidence categories for scoring a basket:

• Slam dunk
• Fairly Certain
• Fifty-Fifty
• Long Shot

In terms of guidelines for probability, I also present ranges of percentage certainty which I typically associate to the terms. This presentation is mainly aimed at calibrating the vocabulary of the group.

• Slam dunk : 100%
• Fairly Certain : ~85%
• Fifty-Fifty : ~50%
• Long Shot : ~20%

What I have noticed is that once the anchor is the Slam Dunk meaning full certainty, the rest would usually be very easily digested by the team.

Wait a minute — haven’t I just said that estimating is not about accuracy? So what about the 100% for a Slam Dunk?

The ambition of full certainty pushes the team to have a deeper conversation about the ticket, for example:

1. Are there any dependencies on this work item?
2. Do we know what the task roughly entails?
3. Are we aware of ongoing work that might impact this work item?

Anything less than a Slam Dunk triggers the same conversation: “Why is this a Fairly Certain and not a Slam Dunk?” “What makes it a Long-Shot?” “What would you need to elevate this Fifty-Fifty to at least Fairly Certain?”. The quest of the group becomes that of clarification on what is missing for this work item to be “Slam-Dunkable”.

Notes from the trenches

I have tried this approach with a number of teams and I have witnessed its strengths and its weaknesses. As any other method, this is no silver bullet and I stick to my philosophy that in this domain of estimating it is what works best for the team to have fruitful discussions that counts, and nothing else.

To conclude this article, I wanted to share some notes about struggles and findings from trenches when using this method, and how I tried mitigating them.

• The method is very intuitive — it requires so little calibration from the team that most of the teams I have experimented this method with have “mastered” it in one session.
• The method gives great material for a retrospective — Consider the case where an item identified as a Slam Dunk was not delivered. If the team was so confident at Sprint Planning there was nothing it could think of that could hamper a work item from being delivered, what assumptions or blind spots did the team have that needs to keep in mind in the future? On the other hand, if a team knowingly committed to an item with lower certainty, a discussion on how to avoid such situations in the future can also easily evolve.
• If basketball gets in the way, think of other sport — football (soccer) can have “an empty goal posts, with no goalie”, running can have a “ solo race”. Feel free to adapt the method in a way that makes it most relevant to your context.
• Teams might get stuck on forecasting or to match confidence with capacity during Sprint Planning — since we are not sizing tasks but judging on confidence teams often (and rightly so) ask “how can we use this information to plan for a sprint?” or “how can we use this information to forecast a project?”. For this I typically suggest the usage of throughput, in other words the trend of work item counts in previous weeks. While no work item is the same, and there will be extremes (both too big, or too small), when looking at a lengthy period in history a trend or pattern could typically be observed.
• Keeping track of estimates on the tickets — how can teams mark their estimates on their work-tracking / project management tools? Some tools might limit its users on the information that they can write in the estimate text-field. In such cases, inspired by No Bullsh*t Estimates, teams can once again resort to a modified Fibonacci sequence, whereby the 1 represents a slam dunk, 2 fairly certain, 5 for fifty-fifty and 20 for long-shot.

If this method intrigues you and you try it out with any of your teams or organisations, reach out and leave feedback on www.matthewcroker.com or reach me out on any of the social media. Enjoy your Slam Dunks.