Fear and Loathing in Story Pointing

In my years as an Agile Coach and Scrum Master, there’s one topic that generates a look of bewilderment on the faces of everyone: effort estimation on the ubiquitous user story. Let’s take a closer look at the confusion and break down the issues at hand.

It comes down to the way the process is explained together with the purpose of user story pointing. In the end, story pointing is all about providing predictability.

Software teams are notoriously unpredictable. Why? Typically, a software team will be building something new, either from scratch or modifying something that was built before that is no longer fit for purpose. In new feature development, there is no cookie-cutter blueprint to follow. They are not building a house. The needs have changed, tooling has changed, the technology has changed and the team itself might well have changed. Basing everything on past efforts isn’t always a good guarantee for knowing how long it will take in the future. I suggest these seven Story Pointing techniques:

1. 1. Don’t think in terms of time

   2. Find a relatable baseline story

   3. Start small, then scale

   4. Factor in uncertainty and risk

   5. Use the same team for estimating and implementing

   6. Convert to time cautiously

   7. Track your velocity

1. Don’t think in terms of time (at least to begin with)

It’s easy to fall into the trap of judging everything in terms of time. One developer’s 6 hours is another developer's 6 days. For example, consider this slide from a not-to-be-named organization’s Agile training video. Admittedly they are calling this “cheating” but really it’s being lazy and completely missing the point.

Let’s avoid referring to effort purely in terms of time. First, the estimating team should be of mixed developer skills and have a reasonable knowledge of the subject domain. Ideally, they should have experience building something similar. We will refer to time in our estimation of effort, but we must also consider complexity, risk, and uncertainty. When the team considers all these factors together, they will choose a value to represent it, relative to other user stories in the backlog. Start with t-shirt sizes (small, medium, large) and ultimately with a numerical (point) value from the Fibonacci series. It’s important to note that story points are a RELATIVE measure, not ABSOLUTE. e.g., a 5-point story is approximately double the effort and complexity of a 2-point story and therefore would take twice as long, whether that be 2 days or 2 weeks.

2. Find a (small) baseline story that everyone can relate to

The important thing here is to find a baseline that everyone can agree to. In other words, is there a relatively small story in the backlog that everyone can identify with or perhaps have had experience with in the past? If not, either go back and decompose the stories until you reach a comfortable level of granularity or invent one that the team can all relate to. We want to find something the team can normalize across the different skill sets and experiences within it. A small story is preferred because humans are more precise at evaluating the effort of narrowly scoped work and less so with broader efforts -- one of the reasons using the Fibonacci series is appropriate here. Document your baseline story and avoid picking a value you can’t go lower on should the stories be broken down even further in the future.

3. Work with small items first, then scale up

Once you have your baseline story in hand, look for user stories of a similar size. Assign values and then begin to compare these smaller stories to their larger counterparts and pick a suitable size for these. Rinse and repeat and always do a sanity to check once you have populated the backlog with more estimated sizes.

4. Factor in uncertainty and risk

There is always going to be a level of risk, uncertainty, dependencies, and unknowns with any user story. It’s very important to acknowledge the aforementioned variables and factor them into the size estimate. I like to call this the wobble factor because the risk may not go away until the team are implementing the story, so we need to inject a margin of error in our estimates for these “what if 💩 happens” scenarios. The team needs to decide what an appropriate value ought to be and how this is applied to any planning and roadmap exercises that need to take place later.

5. Use the same team for estimating as for implementing

Agile is all about team ownership and taking responsibility. We don’t publish a specification list and hand it off to the programmer pool to implement for reasons we all understand well these days. The same must go for effort estimations and therefore we want to use the same development team for the implementation part of product (and process) development as well as in the estimation and planning phase. When this isn’t possible, the implementation team are going to have to understand and feel comfortable with the backlog and how the numbers were derived. This requires that at least some members of the original estimation team spend time with the development team and provide background and context, as well as reviewing the baseline user story (see No. 2) with its allocated size. Try to avoid resizing the backlog unless the team feel it’s absolutely necessary.

6. Convert to time cautiously

At some point, someone is going to want to know how long the development effort is going to take? Any sort of roadmap or release plan is going to refer to a timeline. Ensure that everyone understands that we can’t be 100% confident with durations and dates until the team establishes a track record (see No. 7). Agile authority Mike Cohn, from Mountain Goat Software and Agile Mentors, cautions tying points to developer days because story points are relative and scaling to larger stories isn’t linear. Some of this is addressed by using the Fibonacci series for size estimation and considering the risk and uncertainty, or wobble factor, discussed in point number 4. Apply this to create a range for the duration estimate on each story rather than a single date. Confidence will be higher if the team has a record of past Sprint velocity and is more familiar with its members, the subject domain, and technology they will be working with. If the backlog has been broken down to a reasonably granular level and is well understood, then confidence can be higher. Simply use the past velocity of points-completed-per-Sprint to determine future timelines.

If we must work without a team’s previous velocity data then we are left these options:

1. 1. Create a mock Sprint 0 and load it up with the smaller of the user stories in the backlog, but ones the team would consider implementing early in the project. Do this in the manner of capacity planning so the team feels comfortable with the workload, then remove 20% (teams are typically over-confident in these early stages). Add the points together and this will give you a projected velocity.

   2. If time permits, break the Sprint 0 stories down to their task level and assign hours and again look at capacity and see how the Sprint looks now.

   3. If time is really limited, look at your baseline story and get the team to agree on an acceptable duration for completion. Then roll up your user stories to the feature level and calculate the total points and total time estimate to complete that feature. Now determine how many Sprints it would take to complete the feature. Round up to the nearest whole Sprint. This can be used to determine a projected Sprint velocity. Repeat for other features in the backlog and compare the velocity for each. If the velocity is coming out approximately the same for each feature you can have some degree of confidence that the estimation process is working reasonably well.

7. Track your velocity

A team’s velocity is the measure of how many user stories, and ultimately story points, are completed over each Sprint. At the beginning you will likely see the velocity fluctuate in those early Sprints, but over time the team will normalize and an average can be calculated. This value can be used to predict how long the rest of the product backlog will take to complete. This velocity can be used in the future to determine duration on future product development work for that team.

I hope this provides some helpful hints and guidance around Story Pointing and demystifies the reasons why it’s a useful exercise and most importantly how we go about it. If you have questions or could use a little coaching, Veracity Solutions can help. Click here to set up a call with one of our Agile experts.