Five Steps to Estimate Your Backlog

I come not to praise story points, but to bury them. Long live grains of sand!

Story points are a popular but flawed method for estimating and planning development work. Use this 5-step approach instead to estimate your backlog, keep your projects on track, and eliminate the issues with story points.

Story points became popular because they made it easy to estimate and track large projects, The idea is to create something like a kilometer for work. If you know how “far away” something is, and you know how fast you are going, you can calculate when you will get there. If your velocity changes, you can update your prediction.

Distance = Rate * Time. This is relatively easy math, and much easier than the alternatives.

The problem with story points

The problem with story points is that they are abstract and fragile. There is a lot of misunderstanding about how to use them, and they break if put under too much pressure. What is a better way?

Most Scrum teams no longer estimate tasks in hours. A task must simply be doable in a day or less. To estimate how much work is left in the Sprint, simply count the tasks. We can apply the same approach to the backlog as whole.

Backlog refinement turns massive epics into many little grains of sand. You can use this approach to make better estimates than you can get with Story Points!

Five Steps to Estimate Your Backlog

How does it work? The short explanation: Instead of abstract story points, use small, tangible grains of sand as your “kilometer.”

A grain of sand is a backlog item, that is a small change to the product that is small and well understood, so that it can be turned easily into finished, working functionality.

A grain of sand is small enough that 10 to 12 can fit into a sprint.

Step 0, the Prerequisites

For estimation to work, a couple of things must be true. You need:

1.????? An Autonomous Team: Your Scrum Team is 100% dedicated and has control over its time.

2.???? To be Free of Dependencies: Your team doesn’t need to wait on outsiders.

3.???? Valuable Items: Items have acceptance criteria and are done and deployable every Sprint.

4.??? Small Items Only: Only Grains of Sand go in the Sprint, nothing that is TFB (too f---big).

Step 1: Refine Epics to Features

An epic is a huge “story” or backlog item (regardless of whether it is formally a “User Story” or not”). It is so big, that you would call “NFC” or “TFB” (no clue or too big).

Split it into smaller chunks, which I call features. These are the smallest things you could include in a press release about your product but are probably still TFB to fit into a Sprint.

Step 2: Refine a small item into grain(s) of sand.

At this level, How-To-Demo gives you a workflow to show the feature is working. If the implementation of all the steps can be done by one person in four days or less, or two to three people in less than three days, then it is small enough to be considered a grain of sand. If it’s too big, continue refining, which each step or two becoming a new card.

Step 3: Larger features become many grains.

Counting the grains gives you the estimate. Requiring that 10 items fit in a sprint keeps them tied to reality.

Step 4: Use Traditional Methods to Size Features

Once you have some experience, you can estimate features (that is, TFB-sized backlog items), using planning poker or affinity estimating.

Refine Epics into Features. (TFB, not NFC). Then use planning poker to guess, uh estimate, how many cards the item will be after you have refined it.

If you have refined a feature, and created the Grains of Sand-sized cards, you can count the cards and use the exact count in your calculations. For cards estimated with planning poker, stay with the Fibonacci numbers to avoid false precision.

Warning! A card that has a size larger than one is TFB. Don’t take it into the sprint without refining it properly.

Step 5: Refining validates your estimates.

After you refine a feature that you had previously estimated, you will have a new count of the cards. Remember, plus or minus 50% is normal. Your new count is more precise than your previous estimate, because now you have refined the backlog item and have a much clearer understanding of what is required.

Your estimate might go up because of that understanding, or maybe you are witnessing “scope creep.” When you recognize this, take the opportunity to trim the story back down to size.

Estimating the Whole Project

To estimate the time required to complete a larger project, take your estimate of the total number of grains of sand (you may choose to call them “points”), divide by a conservative 8 or 9 points per sprint to get the time in sprints. (Remember, you are dedicating one grain per sprint to implementing items from the retrospective, right?)

Now multiply the number of sprints by 2 to get the time in weeks or ten to get the time in days. Multiply by your team size to get the estimate in Full-Time-Equivalent days (FTE). I haven’t covered buffering or reserves, but the traditional methods can still be used.

Your benefit

By using small, tangible grains of sand as your point of reference, you eliminate most of the issues that cause pain with story points. They are neither abstract nor fragile, because their a based on simple measures of capacity. You get to keep the simple math of distance, rate, and time.