Estimation

The seventh principle of the Manifesto for Agile Software Development is:
Working software is the primary measure of progress.
Not story points, not velocity, not estimates: working software.

Jason Godesky, Better Programming

Estimation is a common challenge for agile software development teams. The anticipated size and complexity of a task is anything but objective; what is simple for one person may not be for another. Story points have become the go-to measure to estimate the effort involved in completing a task, and are often used to gauge performance. But is there real value in that, and what are the risks of relying too heavily on velocity as a guide?

Agile estimation

As humans, we are generally terrible at accurately measuring big things in units like time, distance, or in this case, complexity. However, we are great at making relative comparisons - we can tell if something is bigger, smaller, or the same size as something else. This is where story points come in. Story points are a way to estimate relative effort for a task. They are not objective and can fluctuate depending on the team's experience and shared reference points. However, the longer a team works together, the more effective they become at relative sizing.

The teams that I coach have all experienced challenges with user story estimation. The historical data tells us that once a story exceeds 5 story-points, the variability in delivery expands. Typically, the more the estimate exceeds 5 points, the more the delivery varies from the estimate.

Robin D Bailey, Agile Coach, GoSourcing

Scale of reference

While story points are useful as an abstraction for planning and estimating, they should not be over-analyzed. In a newly formed team, story points are likely to fluctuate significantly, but there can be more confidence in the reliability of estimations in a long-running team who have completed many releases together. Two different teams, however, will have different scales of reference.

At a company level, the main value I used to seek with story points was to understand any systemic problems. For example, back when Atlassian released to Server quarterly, the sprints before a release would blow out and fail to meet the usual level of story point completion. The root cause turned out to be a massive spike in critical bugs uncovered by quality blitz testing. By performing better testing earlier and more regularly we spread the load and also helped to de-risk the releases. It sounds simple looking back but it was new knowledge for our teams at the time that needed to be uncovered.

Mat Lawrence, COO, Easy Agile

Even with well-established teams, velocity can be affected by factors like heightened complexity with dependencies scheduled together, or even just the average number of story points per ticket. If a team has scheduled a lot of low-complexity tickets, their process might not handle the throughput required. Alternatively having fewer high-complexity tickets could drastically increase the effort required by other team members to review the work. Either situation could affect velocity, but both represent bottlenecks.

Any measured change in velocity could be due to a number of other factors, like capacity shifting through changes in headcount with team members being absent due to illness or planned leave. The reality is that the environment is rarely sterile and controlled.

Relative velocity

Many organizations may feel tempted to report on story points, and velocity reports are readily available in Jira. Still, they should be viewed with caution if they’re being used in a ‘team of teams’ context such as across an Agile Release Train. The different scales of reference across teams can make story points meaningless; what one team considers to be a 8-point task may be a 3-point task for another.

To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better.

So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.

‍Ron Jefferies
Co-Author of the Manifesto for Agile Software Development
Story Points Revisited

Seeking value

However, story points are still a valuable tool when used appropriately. Reporting story points to the team using them and providing insights into their unique trends could help them gain more self-awareness and avoid common pitfalls. Teams who are seeking to improve how they’re working may wish to monitor their velocity over time as they implement new strategies.

Certainly, teams working together over an extended period will come to a shared understanding of what a 3 story point task feels like to them. And there is value in the discussion and exploration that is needed to get to that point of shared understanding. The case for 8 story points as opposed to 3 may reveal a complexity that had not been considered, or it may reveal a new perspective that helps the work be broken down more effectively. It could also question whether the work is worth pursuing at all, and highlight that a new approach is needed.

The value of story points for me (as a Developer and a Founder) is the conversations where the issue is discussed by people with diverse perspectives. Velocity is only relatively accurate in long-run teams with high retention.

Dave Elkan, Co-CEO, Easy Agile

At a company level, story points can be used to understand systemic problems by monitoring trends over time. While this reporting might not provide an objective measure, it can provide insights into progress across an Agile Release Train. However, using story point completion as a measure of individual or team performance should be viewed with considerable caution.

Story points are a useful estimation tool for comparing relative effort, but they depend on shared points of reference, and different teams will have different scales. Even established teams may notice velocity changes over time. For this reason, and while velocity reporting can provide insights into the team's progress, it must be remembered that story points were designed for an estimation of effort, rather than a measure. And at the end of the day, we’re in the business of producing great software, not great estimates.

Looking to focus your team on improvement? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives linked to your agile board in Jira, to improve your ways of working and make your next release better than the last. Turn an action item into a Jira issue in just a few clicks, then schedule the work on the user story map to ensure your ideas aren’t lost at the end of the retrospective.

Many thanks to Satvik Sharma, John Folder, Mat Lawrence, Dave Elkan, Henri Seymour, and Robin D Bailey for contributing their expertise and experience to this article.

Story points can be a little confusing and are often misunderstood. Story points are an important part of user story mapping, and many agile teams use them when planning their work. But they aren't as simple as adding numbers to tasks or estimating how long a job will take.

Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them differently.  

So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.

What are user story points?

Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. You assign a number to each user story to estimate the total effort required to bring a feature or function to life.

When to estimate story points

User stories can be estimated during user story mapping, backlog refinement, or during sprint planning.

Once a user story has been defined, mapped to the backbone, and prioritized, it's time to estimate the story points. It is a good idea to work with your team to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching. Collaborating on story point estimation will also help you spot dependencies early.

It is best to assign story points to each user story before you sequence them into releases or sprints. This allows you to assess the complexity, effort, and uncertainty of each user story in comparison to others on their backlog, and to make informed decisions about the work you decide to commit to each sprint or release.

How to estimate user story points

When estimating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:

• How complex is the work?
• How much work is needed?
• What are the technical abilities of the team?
• What are the risks?
• What parts are we unsure about?
• What do we need in place before we can start or finish?
• What could go wrong?

Tip: If you're having trouble estimating a story or the scope of work is overwhelming, you might need to break your story down into smaller parts to make multiple user stories.

What is a story point worth?

This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).

Here’s how it works:

• Each story is assigned a certain number of story points
• Points will mean different things to different teams or organizations
• 1 story point for your team might not equal the same amount of effort involved in 1 story point for another team
• The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another
• 2 story points should equal double the effort compared to 1 story point
• 3 story points should equal triple the effort compared to 1 story point… and so on

The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint.

Estimating story points for the first time

Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.

Start by choosing stories of several different sizes:

• One very small story
• One medium sized story
• One big story

...a bit like t-shirt sizes.

Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.

The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.

Over time, you and your team will find estimating user stories becomes easier as your shared understanding of the work develops. This is where story points become most valuable, helping your team align expectations and plan more effectively.

Make estimation easier

An app for Jira like Easy Agile TeamRhythm makes it easy to see team commitment for each sprint or version, with estimate totals on each swimlane.

Using the Fibonacci sequence for story point estimation

Some teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).

This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach a consensus much more quickly.

This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.

But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.

Using story points to estimate velocity

After some time working together most teams will have a good idea about how much effort is involved in each story point.

Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.

But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.

You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.

For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.

Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.

As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.

Over time, your estimations should become more accurate.

Using Story Points in Scrum, Kanban, and Extreme Programming

Story points are central to estimation and planning processes in many agile methodologies. Scrum and Extreme Programming (XP) rely heavily on story points to gauge the effort and complexity of user stories.

Scrum teams use story points during sprint planning to decide which tasks to include in the upcoming sprint, encouraging discussion that leads to shared context and understanding of the work.

Extreme Programming on the other hand, uses story points to assess the size of features, enabling teams to prioritize and allocate resources effectively. Teams using Kanban can benefit from story points by using them to set work-in-progress limits and optimize the flow of tasks across the board.

While the specific practices may differ, story points can help encourage team collaboration and a more predictable flow of work.

Agile estimation techniques are amazingly simple yet can sometimes be made more complex than necessary for software development teams. Having experienced the wrath of missing a deadline on previous assignments and fearing 20-hour workdays in the last weeks of a big project, it's no wonder agile team members approach estimation cautiously. How many times has your estimation come back to bite you? 😱

Designed to create a sustainable development pace and provide more realistic deadline expectations for stakeholders, agile estimation techniques use relative sizing rather than predicting real-time estimates.

Popular estimating methods in an agile development environment include story points, dot voting, a bucket system, affinity mapping, and t-shirt sizing. T-shirt sizing is a common agile estimation technique that can be very effective for long-term planning or helping your team get used to relative estimating.

We'll give you a quick review of these agile estimation techniques, but then, we'll dive into t-shirt sizing and the different ways you can use this technique.

Take note of your estimations inside Jira with

Easy Agile User Story Maps

Free Trial

A quick review of some popular agile estimation techniques

If you're reading this article, you're probably already familiar with story points typically used for sprint planning, so we won't spend time rehashing these. However, if story pointing isn't a familiar agile estimation technique, here's an article defining story points and another about specific times when story points might work best on your team.

The other agile estimation techniques we'll review first are more appropriate for road mapping or release planning than sprint planning. Let's run through a quick overview of affinity mapping, bucket systems, and dot voting.

Affinity mapping

In product development, “affinity” refers to similar backlog items, either in terms of types of code, areas of the product, or effort. For affinity mapping within agile estimation, we're talking about grouping work items of similar size. Go figure.

To perform an affinity mapping exercise, the facilitator puts the backlog items on individual sticky notes and attach them to a wall. On another wall, identify one side as "Smaller" and the other side as "Larger." Then, ask the Scrum team to silently move the items from the backlog wall to the sizing wall where they fit based on the item's perceived size, or how long the team will likely take to complete it.

The key to this technique is to move quickly, don't overthink it, and don't discuss it. Once all the items are placed on the wall, team members can discuss which items are potentially sized incorrectly. After a brief discussion, the team can choose whether to move the items.

After everyone is satisfied with the placement, the Product Owner can imagine vertical lines on the wall dividing the backlog into sections and easily assign a t-shirt size to each item and place it on a roadmap.

Bucket systems

A bucket system is similar to affinity mapping, except it expects you to get a little more specific. It uses the numbers 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100, and 200 as relative sizes, and team members put all the backlog items in one of the buckets. Again, this is done silently, but the team is free to discuss any items they feel have been placed in the wrong bucket at the end.

Dot voting

Another way agile development teams can estimate is dot voting. Yeah, it's really about putting dot stickers on note cards or sticky notes. But, this is an interesting technique that brings in concepts other than relative size.

During dot voting, team members receive five dots. Those dots relate to what each team member thinks is the most critical work in the backlog. The importance could come from a technical reason like reworking a database to scale before the next busy season or business value like the most requested new functionality from customer feedback.

Backlog items are then added to the roadmap based on value (the number of dots) and then can be sized for effort using another technique.

As you can see, these agile estimation techniques are especially useful if you have a large backlog that makes you feel like you're herding cats every time you try to organize it. Typically, these estimating processes are used at the beginning of a project, significant feature build, or annual or semi-annual roadmap planning.

Now let's take that deep dive into t-shirt sizing.

T-Shirt sizing for product backlog items

Ahhhh, the t-shirt size. XS, S, M, L, XL — how can that be intimidating? It's so simple and yet so flexible. Mostly used for roadmap and release planning, t-shirt sizing is nothing more than a guesstimate at effort based on the information available at the time of the estimate. That's why it's so basic. It's a guesstimate, and that's ok. 👌

You might be wondering why t-shirt sizing is essential if it's such a ballpark figure and relative estimation. It's helpful for long term planning. Yep, you heard it right. Agile teams plan. If you take a quick look at the Agile Manifesto, the fourth value of agile development teams is:

“Responding to change over following a plan.”

A team can't respond to change if they were never following a plan from the start. Long-term agile planning lets you know if you're setting realistic expectations with stakeholders for the next 6 to 12 months. Or if the company's needs change or existing resources won't suffice and you need to spin up an additional team. T-shirt estimates also help determine how many iterations need to be included in each release to deliver the most value to end-users.

Agile estimation starts as a t-shirt size for planning future releases, then is broken down into story points for sprint planning, and can even be broken down further into hours for sprint execution. Regardless, the main point is this: The closer the work gets to a developer's keyboard, the smaller and easier it is to estimate accurately. The t-shirt size is furthest away from execution, so the estimation isn’t expected to be perfect.

T-Shirt sizing is fast

If you've ever inherited a backlog of hundreds of work items and then received the question "How long will it take to finish all that?" you're not alone. Your first attempt to avoid answering that impossible question might be a good backlog cleansing. Let's say you delete any work item over six months old. I mean, hey, if it's been in the product backlog that long, maybe it's not really that important.

But if you've joined a team just getting started with agile methodologies, you'll probably be stuck with a large backlog and product executives expecting an old-fashioned estimate.

T-shirt sizing comes in handy here. Because it's understood that you're delivering gut-level estimations, your team can power through a super-sized backlog in no time. To ensure team members aren't over-thinking each item during t-shirt sizing exercises, restrict decision-making to 30 seconds per item.

The result is a somewhat organized backlog with relative estimates. The product owner and stakeholders can use that information to decide what to move forward within the short term.

How does t-shirt sizing work?

There are a couple of different ways you can tackle t-shirt sizing depending on your backlog size. For a small number of items, planning poker works great — just ask your Scrum Master to swap out the Fibonacci sequence number cards for t-shirt size letters.

This technique also works well if you need to estimate a subset of a more extensive backlog.

You'll probably want to use a process similar to affinity mapping and bucket systems for large backlogs. Everyone works independently to assign sizing and then discusses conflicts at the end. This technique allows even small teams to get through a large backlog relatively quickly.

Finally, some new agile teams might want to start their estimating journey using t-shirt sizes for user stories and sprint planning. Mike Cohn, one of the founders of Scrum Alliance and an authority on agile processes, suggests that if teams go with that approach, they assign a story point value to each t-shirt size. This technique helps teams get comfortable with story points within the safety net of t-shirt size estimating.

Practice makes perfect with agile estimation techniques

Regardless of the type of agile project you're working on or the estimation process you choose, the more you practice, the quicker your team will become master estimators. 👑 We recommend trying a couple of different methods to see which one feels most comfortable for your team.

One last thing, remember that story point estimates are best for sprint planning. Affinity mapping, bucket systems, dot planning, and T-shirt sizing are better for roadmap and release planning.

If you need help moving your planning off the wall and into Jira, you should try

Easy Agile Roadmaps

Don't forget to check out our other blog articles to help your team on their agile journey.