Agility Without Story Points

How to Provide Reliable Estimates to Stakeholders

What is a Story Point?

Finding a concrete definition for story points is no easy task. Different sources tend to have somewhat nebulous definitions.

One post at Mountain Goat Software describes story points as “a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a … piece of work.” Another definition from scrum.org defines a story point as “a relative unit of measure… to provide relative estimates of effort for completing requirements.”

Many other definitions orbit around relative complexity, difficulty, risk, or some combination, and story points are not equatable to time.

Why Points?

I think it’s important to take a moment to reflect on why we provide software estimates in the first place. Here is what I see as the primary reason for providing estimates.

Estimates provide stakeholders with sufficient information to make business decisions.

That’s the main reason. Future decisions depend on when upcoming work will be complete and the business needs a best guess on when that will be.

Do story points ultimately lead to providing this information to stakeholders? Later I argue they do not do so reliably. Though, story points do have an important benefit.

Story Pointing Forces Early Communication

When the team talks through which point values should be assigned this forces two positive benefits.

1. The team aligns on the intent and scope of stories
2. A misalignment about points leads to a conversation about why someone might think a story is more complex

Both of these are great because early on they lead to one of the Twelve Principles I highly value, effective communication through face-to-face conversations. Unfortunately, subsequently attempting to use points for prediction and communication is where they become unreliable in achieving the overall intent of software estimation.

Why Points Are Unreliable

There are several reasons why story points are often an unreliable strategy for planning sprints and providing sufficient information to stakeholders.

1. The Math Doesn’t Add Up

Because story point values are numerical it is often assumed the math just works out. Over many sprints story points are averaged into a velocity which is used not only for planning upcoming sprints but also estimating project completion dates.

We also acknowledge stories are at times under-pointed or over-pointed and it is often stated these inaccuracies cancel or average out in the long run, rendering those inaccuracies as benign.

In a decade of working with and leading a variety of teams I have not found the empirical data to support either of these claims. It’s not even clear that adding and averaging relative complexity or effort is a coherent concept. Consider the following statement with definitions substituted in.

Based on the team completing stories that amount to a relative complexity number of 28 per sprint, with a relative complexity number of 198 remaining we anticipate completing the remaining stories in 7 sprints.

When read with a charitable amount of skepticism the above statement seems hand-wavy. We have subjectively calibrated relative complexity numbers that are summed, averaged, and extrapolated to estimate a completion date. The part of me that values mathematical rigor raises a red flag with this practice.

2. Relative Complexity Is Subjective

When pointing stories there may be disagreement on what point values to assign. This is the beneficial conversation that is forced to occur early on. However, if you pay close attention to how this pointing disagreement is reconciled the difficulty in comparing stories in terms of relative complexity becomes apparent.

Take a moment and consider what it means for one story to be twice as complex as another. What about three times more complex? Or even a golden ratio more complex?

Complexity and effort are notoriously difficult to quantify, let alone quantify objectively, and we tend to rely on more subjective reasons for justifying point values.

Person 1: This story feels more risky because it was hard the last time we worked on a similar story. I feel that moves it from a three to a five.

Person 2: Now that we know which rabbit holes to avoid I feel that it should actually be a two pointer. Our lessons learned make it less risky this time around.

I’ve witnessed this kind of conversation tilt either way many times before depending on how assertively a position is argued for. The conversation also tends to result in comparing a tally of reasons for and against certain point values without cleanly mapping on to a complexity / effort scale. In other words, assigning point values tends to be a highly subjective practice.

3. Effort Is in the Eye of the Implementer

A frequent claim from story point proponents is story points transcend the individual doing the work. A three pointer for you is the same as a three pointer for me.

This claim is very often not true because individuals often approach the implementation for a story differently leading to varying levels of effort due to a variety of factors.

• Familiarity with the domain
• Familiarity with the technology
• Unanticipated detours
• Knowledge of best practices
• An ability to foresee potential issues

Depending on how these dials are turned a three pointer for one person is not necessarily a three pointer for another which again brings into question the predictive reliability of story points.

If Not Story Points, Then What?

Let’s start by making a few concessions.

• Accurate estimates don’t exist. This statement is more definitional than anything. Estimates are informed guesses that are often inaccurate. It’s a constraint to be accounted for.
• Estimates are relative to the individuals doing the work. Different individuals often approach the same problem from different angles. We bring our own experiences, knowledge, and even preferences for tools. These differences easily impact effort and complexity.
• Estimates intrinsically have two dimensions: Time and Confidence

Estimates are intrinsically two-dimensional. Consider a hypothetical for estimating how long it will take you to travel to an appointment during rush hour. First, let’s acknowledge that providing this estimate never comes in the form of “I’ll be there in exactly 17 minutes” or “It’s half as complex as towing a boat to the lake”.

Rather, we provide a rough timeline hedged by confidence based on circumstances we may encounter. There may be road construction, a car accident, or other situations. With these factors considered we tend to give estimates similar to “I’ll probably be there in about 20 to 25 minutes” and we subsequently update the estimate for the remainder of the journey as we learn more.

A Two-Dimensional Estimate

Notice in the time vs confidence graphic how the bottom and right edges are not terribly useful aside from communicating how much we don’t know or how large that work is.

Ideally we find ourselves in the upper left square where work is small enough that we can have a decent degree of confidence when estimating. We can take this idea and map it on to sprint terminology.

The above chart is one I’ve used in the past to help plan sprints. By using this chart we see either a story is sufficiently small and sufficiently well understood that we can attach a Small or Medium label to it, or it’s too large and needs to be broken down into well-understood parts, or we need to spend time further clarifying the work.

Because sprint stories will be sufficiently small and sufficiently well-understood it’s not terribly difficult to plan out what each team member can accomplish for a given sprint without relying on an average story point calculation.

Story Ownership & Daily Committable Work

Ownership as it relates to the SDLC in an interesting topic generally and it applies to estimates specifically really well. The idea is simple. Whoever is working the story owns the story including breaking it down if it’s too large, asking questions if it needs clarification, or estimating whether it is Small or Medium. Of course, none of this pre-work necessarily needs to be done in a vacuum and team members are encouraged to bring in help and additional perspectives.

This allows us to get closer to the idea of daily committable work. As the phrasing suggests, when planning and executing on a sprint the goal is to identify work small enough that it can be scoped to about a day. As each day passes we should expect to see this daily work move across the board, thus communicating to stakeholders and the rest of the team a good sense of progress on the sprint.

Estimating Project Completion Dates

Using this system, how can we communicate if the project will be completed next week or in three months? Don’t we need some kind of velocity and burn down?

In my experience, I’ve not seen velocity to be a reliable statistic and using it to extrapolate dates for project completion often gives a false sense of confidence to stakeholders. Said differently, velocity does not reliably provide stakeholders the information they need to make decisions. There is a better way and it comes from the agile manifesto principles.

Prefer face-to-face communication.

Though face-to-face communication doesn’t automatically produce estimates for project completion, having frequent open and honest conversations with stakeholders will ultimately help achieve that intent. Frequent conversations allow all participants to ask questions and attempt to understand progress through an empathetic lens. Which items are more risky? Why do we think this feature will take a little longer and how does that impact the overall plan? Can we reprioritize something?

When stakeholders are frequently brought together to have honest conversations about current progress and expected completion what need is there for a burn-down chart, velocity, and ultimately story points?

Agile Estimates

While some teams find story points and velocity useful those concepts are often unreliable for many of the reasons described above. Rather than trying to force the notion of relative complexity and effort into an objective mathematical framing, consider an alternative that can more reliably achieve the intent of software estimation.

• Embrace two dimensional estimates
• Ask the person doing the work to own the work and provide estimates
• Break work down into daily committable tasks to confidently communicate daily progress
• Lastly, empathetically communicate overall progress and expectations through frequent and open conversations with your team’s stakeholders