Customize Your Agile Approach: What Do You Need for Estimation?

Many agile approaches assume teams will estimate with story points, which leads to a project velocity measure. But our intuitive notion of velocity says that the distance is a standard, repeatable measurement. Most teams don’t have normalized points within the team and certainly not between teams. Instead of velocity, consider counting stories or using cycle time for estimation. You might not need to measure velocity at all.

This is the third in a series of articles that will help you think about how you might want to customize your agile approach for your context. This article is about the what you might estimate and when.

For every project I’ve worked on--my own and for organizations--someone has wanted to know how long it would take. That makes sense, if you’re thinking about an order-of-magnitude estimate. Your team might be able to say, “We’ve done a couple of projects like this in the past. One took us three months. The other project took us 13 months. We think the requirements--as far as we know--look more like the three-month project. However, the code base has changed, so here’s a guess: six months and we’ll be able to estimate better after the first couple of weeks, once we get into the code in more depth.”

That’s a reasonable first step in estimation. However, too many teams I know use story points as a way to estimate. This can create problems, mostly because people misunderstand velocity.

Velocity is a Point-in-Time Capacity Estimate

Velocity is a rate of change coupled with direction. Too often, people mistake velocity for acceleration. Velocity is not acceleration.

Imagine you’re walking or running around your neighborhood for exercise. Your exercise goal is to walk or jog two miles every day.

In the spring, summer, and fall, when the weather is good, you can jog at a pace of roughly 4 miles/hour. You finish your jog in 30 minutes.

However, you walk or jog every day, regardless of the weather. When it rains, you don’t run; you walk. And, you walk slower because you’re not wearing good walking shoes. Instead, you wear rubber boots so your feet don’t get wet. You walk at a different pace: 3 miles/hour. You finish your walk in 45 minutes.

And, in the snow, you don’t even make 3 miles/hour. You wear boots and you slow down so you don’t fall in the snow or on ice that you might not be able to see. You are down to 2 miles/hour. It takes you an entire hour to walk the same distance.

You still walk the same distance every time you walk. However, there is one big distinction: you’re not walking at the same velocity. You don’t complete the same distance in the same time as you might want to. It depends on the weather, your footwear, and the condition of the roads.

It’s the same problem with a software team. The team’s velocity depends on a stable rate of completion. Here are the factors that affect your team’s stable rate of completion:

1. Story size. The larger the story, the more risk the team faces in being able to complete it when they think they can. And, even if your team is accurate about sizing larger stories, remember your customers buy stories, not story points. See Customize Your Agile Approach: Start with Results to see burnup charts about reporting stories complete instead of story points.
2. The current state of the code and tests. The more automated unit tests and system tests in that area of the code base, the less risk the team face when they add or change features.
3. Team stability. When the team has stable membership, the team can assume their history will carry forward. However, if the team changes membership--even with just one person--the team is unlikely to maintain the same velocity. New people have to learn the code base and how this team works.

You might think that if the same team always estimates in story points, the team should be able to predict what they can deliver. I have found story point estimation to be useful if the stories are one- and two-day stories, maybe as large as three-day stories.

However, the larger the stories and the more the stories vary in size, the more difficult teams find the story point prediction. That’s because the relative risk is higher the more story points.

One team has historical data that says it can deliver 42 story points per iteration. They mostly have 1, 2, and 3 story-point stories. Those stories take roughly a half day, one day, and 1.5 days each. That means they can work relatively independently and finish their work.

However, in their next iteration, they selected three 13-point stories (39 points) and one 3-point story. That adds up to 42 points. However, the first 13-point story, even when they swarmed on the story, took them eight full days.

The team wasn’t stupid or lazy. They underestimated the complexity and the areas of the code the story touched. That’s because the larger the estimation units you measure in, the more your estimate can be off by those units. (See Predicting the Unpredictable for a larger explanation of this phenomenon.)

Story points can have meaning if your stories are roughly the same size. However, several one and two point stories are not necessarily the same effort as a five or eight point story.

Instead, think of velocity as a capacity measure where, you can, on average, deliver some number of stories, some number of fixes, and whatever else your team delivers on some form of cadence. That’s one way to estimate.

Maybe that’s not quite enough for you. Many agile teams use relative estimation.

Use Relative Estimation as a Team

If you’ve been using agile approaches for a while, I’m sure you’ve heard of relative estimation with planning poker. Teams get together to estimate the work they will do in this next iteration. Each person has a card with either numbers such as the Fibonacci series, or t-shirt sizes. As the PO explains the story, the team members hold up a card to explain how large they think this story is.

Every team member doesn’t have to agree on the relative size. The conversation about the sizing is what’s important. The team members discuss the code, the design, the tests (or lack thereof), and other risks they see.

The conversation is critical to the team’s understanding of this story. And, when the team decides that the story is larger than a “1,” the team knows there is uncertainty in the estimate. (See Pawel Brodzinski’s Story Points and Velocity: The Good Bits for more details about this estimation problem.)

Avoid Task-Based Estimation

Some teams try to break apart the work into tasks. I have a problem with task-based estimation. Too often, I see teams try to use resource efficiency, where we optimize by person, instead of flow efficiency, where we optimize by team. When teams lose sight of the team’s job--to move the story across the board to done--they have too much work in progress. Too often, they don’t release features. Instead, they release partially completed work that doesn’t add up to a feature. That work doesn’t help the customers. Teams start to count points completed instead of counting features completed.

Instead, consider how you can use story sizes greater than one day to understand uncertainty. If you want to use your relative estimation to understand your uncertainty about the work, here are some guidelines:

• Remember that your estimate will be off by the estimate units. If, for example, you have a three-point story, your estimate might be plus/minus three points. That starts to become a problem if your stories are 8, 13, or more. In that case, your 8-point story might actually take you the equivalent of 16 points.
• Ask yourselves why you think this work is so large. Here are some possibilities: the code is a mess; there are insufficient unit tests or automated system tests to be able to check changes; the work is much larger than one story--it’s an entire feature set.

While you might find tasks useful when discussing a story, remember that your customers can’t use the task output. Your customers buy and use completed features.

Especially for large stories, tasks might help you realize where you have uncertainty in this work. I don’t recommend the team split the work by task. However, you might find that once your team starts to list the tasks, you can better assess the risks and uncertainty for this story. You might even discover smaller stories that you can better estimate and deliver sooner.

Spike to Clarify the Work

I happen to like one-day stories--when the team can complete a story in one day. You might be wondering how a team can complete a story in a day. When a team swarms or mobs, the team can complete stories faster than one person can by him or herself. (See Pairing, Swarming, and Mobbing for more details about how your team might use swarming or mobbing.) Remember, in agile approaches, it’s not about what one person can do; it’s about the team’s ability to move features to done.

You might be wondering about my perspective about pairing, swarming, and mobbing vs. individuals taking work themselves. Agile approaches work well when the team collaborates to move a story from Ready to Done, regardless of the columns on your board. Too few teams take advantage of collaboration within the team. Too many teams collaborate with customers or users, but not as team members. Pairing, swarming and mobbing all help every team member learn the product details and deliver a more valuable product. (See How Pairing & Swarming Work & Why They Will Improve Your Products for more details.)

Too few POs and teams are able to create stories that are one day in duration. They don’t see how to break apart a “story” so that it’s one day long. The team can use the larger story points to discuss uncertainty. For example, if a team realizes that an eight or larger point story has too much uncertainty, the team might have a policy of either workshopping the story more, spiking it, or mobbing on the story to complete it. Or, the team, along with the PO, can workshop the “story” and see if it’s an entire feature set or a compound story. Or, the team can use a one-day spike to understand the story better.

Here’s how one team used a one-day spike to explore, deliver, and more fully understand the story. Jim was the PO for a six-person team: four developers and two testers. He had visited a customer and knew what the customer wanted, and he could only see the total feature set. He had trouble breaking apart the feature set into the several stories. He asked the team to swarm to help him see the risks.

1. The team met at 1:30pm, after their lunch break. (As long as the team gets together to work together, they don’t have to meet in the literal morning; the day can start whenever everyone is ready to work together.)
2. The team agreed on these deliverables: deliver one small feature and answer these questions:
   1. What are all the stories for this work?
   2. Where are the risks?
   3. What is the first value we can deliver?
3. The team had decided they would work until 5pm that day, allow people to leave or check email and get back together at 10 the next morning. They would then work until their 12:30 pm lunch and meet with Jim at 1:30 the next day. That would be their one day of work.
4. The team decided to first pair as developers and testers to understand how the entire feature set might work and then see what to do next. They might have decided to swarm or mob from the beginning, but they had so much uncertainty, they decided to pair and then meet in an hour. Here’s how their day proceeded:
   1. At 1:30pm, Jim explained the goals he wanted for the customer. The team members asked questions which he answered. Jim had a rough idea of what done meant for the work, but he wasn’t totally sure. Jim wanted to iterate with the team.
   2. At 2pm, the team split into two pairs of developers and one pair of testers. They agreed to meet again in an hour, at 3pm.
   3. At 3pm, the team members returned to their team room. Each pair explained what they had discovered and what they had finished during that hour. They decided not to switch pairs at this point.
   4. At 4pm, the team met again to see where they were. One of the developer pairs had a prototype they wanted to ask the team and Jim to comment on. The tester pair had some automated tests they wanted feedback on. Jim was able to provide feedback and comment on the tests. Jim refined what he wanted and the pairs continued to work in the same pairs as before.
   5. At 5pm, the team met again with each other and Jim. Now, they were on the right track. Some people left at 5:15, the normal end of their day. The other team members processed emails, leaving the remaining work until the next day.
   6. At 9:30am the next morning, everyone had returned to work and had processed enough of their email so they could return to the team’s work. The team had a brief meeting to reconnect, continue their pairs, and decided to meet again at 10:30am.
   7. At 10:30am, the team met again to ask Jim for more feedback. By now, both developer teams had prototypes that they needed to explain to Jim and the rest of the team. The testers had more automated tests which helped the developers know what done meant. Jim provided more feedback. Now, the pairs became two triads: two developers and one tester each.
   8. At 11:30am, the team members met with Jim again. Each triad had completed one small story with automated unit tests and automated system tests. The team could see where the stories were. They spent the next 30 minutes with Jim, workshopping the remaining stories. The team was able to answer the questions, explaining that performance for this feature set was a big risk.

This particular team used pairs and triads to swarm. Other teams choose to swarm as individuals, where each person works by him or herself for a timebox and then checks in with the rest of the team every hour or so.

However, they might have decided to mob. If they had mobbed, they might not need the hourly checkpoints, especially if Jim was in the room with them.

When the team works through the spike as a team, they learn what they can complete in one day. They also learn what remains to be done for all that work and where the risks might be.

If the team realizes the work is still quite complex, they have options: consider another spike day, workshop the work with each other and the PO, or to estimate the work as they see it. 

Instead of estimating by size, take the ideas of capacity one step further, and consider counting your stories.

Count Stories Instead of Estimating

One benefit of counting stories is that the team will tend to normalize stories to a comfortable size for that team. One team might like one-day stories. Another team might like three-day stories. In any case, the team will work to “right-size” stories for that team if they count stories.

You might wonder if the counting causes the story normalization or if the team can normalize stories to a reasonable size if they count. It doesn’t matter which is first, normalization or counting. The key is that the team focuses on what they need to deliver: completed stories. Once they start to count those, instead of story points, they change their behavior. (See Customize Your Agile Approach: Start with Results You Want to see how to measure stories instead of points.)
 

One team, new to counting stories, thought they could ignore the relative story size. One iteration proved to them that they needed to either review story size or measure their cycle time.

Counting stories allows the team to see their throughput easily. And, because counting tends to help the team normalize the story size, the team doesn’t have to estimate much, if anything at all.

Instead of spending time estimating, the team and the PO spend time making the stories roughly the same size. One story might take a little less time and another story might take a little more time. Over time, each story becomes a similar size as all the others.

As another benefit, teams don’t get stuck in task-based estimation.

If you want to use data to count your stories, use cycle time. Cycle time is the time it takes a team to work on and move a story to done. You might use a table similar to this if you’re working in iterations:

If you work in flow, measure your cycle time for the most recent five or six stories and you’ll have a reasonable approximation of cycle time.

Now that you know that each story takes on average 2.5 days, the team can say, “We can finish about four stories per iteration.” That’s a useful count.

Consider #NoEstimates

You may have heard of the NoEstimates movement. The idea is that you have a constant flow of work through the team, so you don’t need to estimate anything. For NoEstimates to work for you, the stories have to be small so the team can continually flow completed work out for review.

Sometimes, a team’s estimates aren’t useful anymore. If you’ve had these experiences:

• A product owner who wants to change the stories after your team committed to them
• The team realizes small stories aren’t small
• The team realizes the code base or test base isn’t what they expected

The team realizes the estimates aren’t useful. In that case, counting stories might help the team more than estimation.

Remember, if your team provides a working, demonstrable product to your management or customers every week or two, you might not need estimates at all.

Summary

Teams have many options for estimating. I have not found it useful to use story point velocity as a way to predict what a team can finish, unless the team makes the stories small, as in one or two day stories. I have found cycle time useful in all circumstances. That’s because cycle time takes your team’s historical data and uses that.

If you need to estimate your team’s work, see if you can create one-day stories and count them. If you can’t, consider spiking the work and delivering some finished feature in one day, plus the remaining stories.

If you can, see if your team can flow work, delivering a completed story every day. That might free you from estimates altogether.

About the Author

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Rothman is the author of more than ten books, including: Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile and Lean Program Management: Scaling Collaboration Across the Organization, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed., See more of Rothman’s writing at jrothman.com.