How many stories does your team estimate per hour? How accurate are those estimates? Current methodologies don't always work well. There is a better way.
Many teams struggle with estimating stories. I’ve come across teams that have no stories estimated, that have only some stories estimated, or that put estimates on tasks or stories that are measured in hours instead of using story points.
There are several reasons for this. Some teams don’t understand how to use story points. Others don’t know how to do relative estimation. And others use techniques that are too slow, so they run out of time to do their estimations.
Introducing fast estimation
Our teams invented a technique we call "fast estimation,” or FAST (for FAst eSTimation). It draws from two other techniques: the well-known planning poker, and another that I read about in The Elements of Scrum, by Sims and Johnson. It’s a great four-hour read for those just getting started with agile or Scrum.
Our teams went to dozens of teams and had them answer my opening question. We found that most teams thought they could do between five and eight stories per hour. We also measured their sprint plan accuracy, but we found that the trends in that data were more aligned with team maturity than with their estimation techniques.
Then we had the teams switch to fast estimation. The result: The teams estimated 30 to 40 stories per hour, with no loss in accuracy—a 375% to 800% improvement in productivity.
Fast estimation is five to eight times faster than other techniques, with similar accuracy. So where does your team lie? If you're on the lower end of the estimation spectrum, then you'll definitely benefit from FAST.
The idea behind FAST
Fast estimation has two major goals: 1) Never have a story, feature, epic, or project that's unestimated; 2) Maximize the speed of estimation, while preserving the quality of estimation.
Faster estimation means your teams are more likely to estimate everything immediately upon creation. Having everything estimated leads to much stronger release predictability metrics. The only real question is: Does your estimation quality suffer when you start estimating faster?
Before there were story points, many teams simply counted every story as 1 point. Some were bigger and some smaller, but teams felt that it would all even out. And despite some variance due to story size, teams could still predict approximately how many stories they could get done for each sprint.
This technique has a wider variance in velocity but has zero time needed for estimation, which is in itself a productivity boost. And note that Kanban uses this approach. It counts every ticket as one item and simply looks at the range of variance for estimation purposes.
To tighten up the variances that just counting stories had, story size was adopted. Some teams used T-shirt sizing (S, M, L, XL, etc). This gave better fidelity as to how many stories the team could do in a sprint but was clumsy for understanding overall size (you can’t add S+XL and get anything meaningful).
Finally, people used a Fibonacci sequence, in which each item gets a size that's a Fibonacci number. These numbers could then be added to get a total size for whatever the team was estimating.
Here's a tip: Whenever people get bogged down on estimation (It’s a 5! No, it’s an 8!), remind them that we could just go back to calling everything a 1 and still get pretty good planning and predictability. Tell them to stop bickering over small changes.
Relative estimation and Fibonacci
If you are already a master of relative estimation, skip to the next section. For everyone else, the questions often come up: “Why use relative estimation?” And “Why the Fibonacci series?”
Humans aren’t great at guessing how big something is, but they are good at sorting things from smallest to largest.
The larger the items get, the harder it is to guess at small differences. In the illustration above, the one-story house is easily discernable from the two-story house. But if you were looking at two skyscrapers and one was 100 stories tall while the other was 101 stories, could you tell at a glance which one was taller?
This is why we use Fibonacci numbers for estimation. As effort increases and becomes harder to predict, the gaps get bigger. While you can’t see a one-floor difference at 100 stories, you can tell which skyscraper is taller if one is 100 stories and the other is 60.
Note that "agilists" use a modified Fibonacci, which follows the normal sequence up to 13. But then they go to 20, 40, and 100. For the life of me, I can’t understand why. They say that 21 sounds falsely precise, to which I say, so does 1, 2, 3, 5, 8, and 13. It’s all falsely precise. But even more mysterious to me is that, even though 20 plus 40 equals 60, they omit it.
My teams use 60 all the time. It’s our compromise.
Oh, and if you weren’t aware, the Fibonacci sequence adds the last two numbers in the sequence to get the next number. So 13 should be followed by 21, and then 34, 55, 89, etc. My math sense would prefer we stick to that. But I can live with the modified scale (as long as we bring 60 back to town!).
Here's the bottom line: The numbers you use to estimate get farther apart faster as things get vaguer. And that's what makes estimation more accurate and much easier.
The three variations of FAST
Okay, time to learn our secret sauce. There are three versions of fast estimation you can use, depending on your team and backlog maturity level:
- Fast estimation technique A: New backlog
- Fast estimation technique B: Existing backlog, new team or team members
- Fast estimation technique C: Existing backlog, no new team members
Regardless of which version you ultimately decide to use, you should spend the time to learn all three. They share some commonalities, starting with the following estimation working agreements, which are part of the secret sauce of FAST. Adopting these agreements while keeping your current estimation technique will result in a serious productivity boost all by itself.
First, consider the quality assurance working agreements:
- A team estimates together.
- Product owners and Scrum masters should estimate with them.
- The votes of team members doing the work trump those of product owners or Scrum masters.
- When the product owner says an estimate should be higher, that’s odd. You are probably missing requirements.
- When a team member says an estimate should be lower, that’s odd too. There are probably built-in functions you don’t know about. Discuss those.
Then consider the real productivity-boosting agreements:
- If the vote shows everyone is in agreement on size, you are done. There's no need for acceptance criteria or any detailed discussions. Wait until sprint planning for those, or story refinement sessions if you do those.
- If the size is one Fibonacci category off (say 5 vs. 8), just pick the higher one. Don't bother discussing why. Wait until sprint planning, and remember, you could just use the “they are all 1” technique, so 5 vs. 8 is just noise in the machine.
- If the estimate votes are two categories off (say 3 vs. 8), go with the middle number (5). Do not bother discussing, as described above.
- If the estimate is three or more categories off (say 3 vs. 13) proceed as with planning poker, and have the low and high advocates discuss why they are on such vastly different pages. Everyone else can chime in. Once the discussion is done, revote.
- Work quickly; don’t try to be perfect. Close fast estimates are far better than slow, “more exact” ones.
Understanding your FAST options
So far I've explained why my team came up with fast estimation and how this technique can bump your estimation process productivity into the range of 30 to 40 stories per hour. I also explained why agile teams use relative estimation and why they choose Fibonacci sequencing, described some powerful estimation working agreements, and identified the three flavors of FAST. Now it's time to dive into each in detail so you can decide which to choose.
FAST option one: A new backlog
By “new backlog,” I mean a backlog that hasn’t been estimated before. The backlog itself could be new or old, but it doesn’t have any points on it yet.
You estimate in two passes, so be sure to go fast! Even after the two passes, you can still re-estimate during story refinement and sprint planning, so go quickly. This is estimation, not exactimation. If you tend to be very precise in your thinking, you may feel uncomfortable with moving so quickly. But after bringing stories to done a few times, you'll understand that it’s okay to go fast at this stage. In round one, you place your backlog in order from smallest to largest. Then, in round two, you put Fibonacci numbers on your sorted backlog.
Round 1: Place your backlog in order from smallest to largest
- Take turns. The product owner and Scrum master take turns too.
- The first person takes any two items off the backlog and puts them in size order, from smallest to largest. That person's turn is then done.
- Everyone after the first person either says, “I agree with the order so far,” or moves any single item to a different spot and explains why. Discuss further only if people disagree. Hopefully, they don’t. Then...
- Take one new item off the backlog and place it in relative order to the other two.
- Continue until all the stories are placed, everyone has had two turns, or an hour passes.
If any stories are left unestimated, use techniques B or C below on those later. However, browse all the ones that are left. If there are any very small ones that didn’t get sorted, grab them and put them on the small end of your sorted list. In other words, if you have to leave some stories unsorted, be sure you have the smallest stories on your sorted list.
If you have a very large backlog, you can do a pass zero. Simply tag things as small, medium, or large. Then just work on the smalls first, then mediums, and finally larges. This will effectively cut your starting backlog by one-third.
Work quickly, and don’t try to be perfect. More rounds are coming that will refine your first cut. Just get them close to smallest-to-largest order.
Round 2: Put Fibonacci numbers on your sorted backlog
At this point, your backlog, or part of it, should be in smallest-to-largest order.
- Your smallest item is a 1.
- Move up the line. Is the next item also a 1, or a 2, 3, or 5? Because you sorted the list first, you are comparing things that are close to each other in size. And it is much easier to put a number on close neighbors than on far ones. For example, how many ants does a small dog weigh? That's hard to say. But when you ask, "How many cats does a small dog weigh?" you might say, "About three, depending on the breed." So if a cat is a 1, a dog is a 3.
- If you have any bizarrely small items, make them a half. Note that you can do this as a group rather than taking turns.
- You will notice some things are out of place from the first pass. You might think, Wow, how is this one so hard? Or so easy? Well, you can move it. That’s why the first pass doesn’t have to be perfect. This step will find the errors from round one.
- Always go fast. Remember, these could all just be a 1, so this extra fidelity doesn’t have to be perfect.
Fast estimation technique B: Existing backlog, new team or team members
In this scenario, you have estimated your backlog using technique A. Now new work comes onto the list, or maybe you have a big backlog and can't get it all estimated using technique A.
Technique B is faster than A. Remember that fast estimation has a goal of zero unestimated items on the backlog, and fast techniques are important to that goal. This technique is extremely quick, if you follow these three steps:
- Sort your backlog from the smallest story to the largest.
- Run your new item down the list until it seems to be around the same size as the items. If it's too high, your new item will feel too big. If it's too low, your new items will seem too small. Goldilocks it.
- Whatever the size of the items that you land near, make that the size of your new story.
Fast estimation technique C: Existing backlog, no new team members
At some point, your team members will fully understand what a point means to them. When this happens, you won’t even need to sort the backlog and compare a new item. The second your team sees it the members will say, “Yeah, that’s an 8.” If anyone disagrees, you’ll use the working agreements above to size it in a matter of seconds.
The technique becomes so fast that it becomes impossible not to estimate every item in the backlog. By the time you open the tool to add it, you’ve already decided on its size.
But note that if you add a new team member, you will need to slow down and return to technique B until the person gets the hang of it. One trick is to allow the new member to sort the backlog and estimate all new work, asking any questions he or she needs to make a guess. This is the fastest way to get new people as familiar with your size categories as your more mature team members.
And remember that agile asks for dedicated teams. This is a great example of how messing with team membership lowers productivity in a “J curve” until such time as the new member catches up.
Go forth and start FASTing
Each of the three FAST techniques described above is faster than the previous one: Technique A is the slowest, and C the fastest. But most teams need to move through all three before they can master technique C. Fast estimation also enables many other skills, such as release planning and agile portfolio management.
FAST has clear advantages over other methods for determining how many stories your team can estimate. Follow the FAST technique and you'll be on your way estimating at a rate of 30 to 40 stories per hour, rather than the more typical 5 to 8. And you'll be just as accurate.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
