Estimation

TL;DR

Anti-patterns in agile feel familiar, but often quietly undermine progress. In this guide, we explore five common collaboration traps: large user stories, forgotten retro actions, superficial estimation, premature "done" labels, and ceremonial agility. You'll learn how to recognise, understand, and experiment your way out of them.

The Comfort Trap: Why Familiar Agile Habits Hold Teams Back

In agile, anti-patterns don’t announce themselves. They slip in quietly, posing as good practice, often endorsed by experience or habit. Over time, they become the default - until velocity stalls, engagement dips, and retros feel like re-runs.

In our conversations with seasoned coaches and practitioners across finance, government, consumer tech, and consultancy, we realised one thing - anti-patterns aren’t just a team-level concern. They signal deeper structural misalignments in how organisations think about work, feedback, and change.

To protect the privacy of our interviewees, we’ve anonymised company names and individual identities.

Let’s unpack a few of the most pervasive anti-patterns hiding in plain sight, and how to shift them without disrupting momentum.

1. The Giant User Story Illusion

Large User Stories: Oversized tasks that delay feedback and blur team accountability.

"It felt faster to define everything up front. Until we got stuck." - Product Manager, global consumer organisation

Large user stories promise simplicity: one place, one discussion, a broad view stakeholders can get behind. But when delivery starts, the cracks widen:

• Estimations become guesswork.
• Feedback loops stretch.
• Individual contribution becomes unclear.

In many teams, the difficulty isn’t about size alone - it’s about uncertainty. Stories that span multiple behaviours or outcomes often hide assumptions, making them harder to discuss, estimate, or split.

Symptoms

• Stories span multiple sprints.
• Teams lose clarity on progress and ownership.
• Estimation sessions are vague or rushed.

Root Causes

• Pressure to satisfy stakeholder demands quickly.
• Overconfidence in early solution design.
• Lack of shared criteria for 'ready to build'.

Remedy

‍Break stories down by effort, known risks, or team confidence. One team created their own estimation matrix based on effort, complexity, and familiarity—grounding pointing in delivery, not abstraction.

See also: The Ultimate Guide to User Story Mapping

2. Retro Amnesia: Action Items with No Memory

Incomplete Retro Actions: Items raised in retrospectives that quietly disappear, losing learning and team trust.

"We come up with great ideas in retros, but they disappear." - Agility Lead, multinational financial institution

When teams can’t see which actions carried forward, improvement becomes accidental. One coach described manually collecting and prioritising past action items in a Notepad file - because nothing in their tooling surfaced incomplete actions by default.

Worse still, valuable decisions get revisited unnecessarily. Teams forget what they tried and why.

Symptoms

• Recurring issues in retros.
• Incomplete actions vanish from view.
• Team energy for change drops over time.

Root Causes

• Retros run out of time before reviewing past items.
• No tooling or habit for tracking open actions.
• Actions lack owners or timeframes.

Remedy

‍Surface incomplete actions in one place and track progress over time. Revisit context: what triggered the decision? What outcome did we expect?=

3. Estimation Theatre: When Story Points Become Currency

Story Point Anchoring: The habit of assigning consistent points to avoid conflict, not to clarify effort.

"The team got used to anchoring around threes. Everything became a three." - Agile Coach, public sector agency

Story points should guide shared understanding, and not become a measure of performance or predictability. But many teams fall into habits:

• Anchoring to previous estimates.
• Avoiding conflict by picking the middle.
• Gaming velocity for perceived consistency.

Symptoms

• Homogeneous story sizes regardless of work type.
• Few debates or questions during pointing sessions.
• Velocity becomes the focus, not team clarity.

Root Causes

• Misuse of velocity as a performance metric.
• Comfort with consistency over conflict.
• Absence of shared understanding of story complexity.

Remedy

‍Reframe estimation as shared learning. Encourage healthy debate, try effort/risk matrices, and use voting to explore perspective gaps.

4. The "Done Means Done" Shortcut

False Completion: Marking items “done” when no meaningful progress was made.

"We mark items as done, even if we didn’t act on them." - Scrum Master, insurance and data services firm

Marking something "done" in order to move forward can feel pragmatic. But it hides reality. Was the issue resolved? Deferred? Invalidated?

Without clear signals, teams lose the ability to reflect truthfully on what’s working. One team described starting every retro with a conversation about what "done" actually meant, and adjusted their practices based on whether action was taken or just abandoned.

Symptoms

• Completed items have no real impact.
• Teams disagree on whether actions were truly resolved.
• Follow-up problems recur with no reflection.

Root Causes

• Ambiguity in what "done" means.
• Lack of closure or accountability for actions.
• Reluctance to acknowledge when something was dropped.

Remedy

‍Introduce a "no longer relevant" tag for actions. Start every retro by reviewing outcomes of previous actions, even if abandoned.

5. Anti-Patterns in Disguise: Agile vs Agile-Like

Ceremonial Agility: Teams follow agile rituals but avoid meaningful feedback, adaptation, or empowerment.

"We're agile. But we also push work through to meet delivery at all costs." - Project Manager, large enterprise tech team

Many teams operate in agile-like environments: sprints, boards, and standups, but decision-making remains top-down, and trade-offs go unspoken.

This hybrid approach isn't inherently bad - context matters. But when teams inherit agile ceremonies without agile values, collaboration becomes box-ticking, not problem-solving.

Symptoms

• Teams follow agile ceremonies but avoid real collaboration.
• Delivery decisions made outside of sprint reviews.
• Retrospectives focus only on team morale, not system change.

Root Causes

• Agile adoption driven by compliance, not culture.
• Delivery commitments override learning and adaptation.
• Leadership sees agile as a process, not a mindset.

Remedy

Is your agile framework enabling change - or disguising command-and-control? Use retros and sprint reviews to discuss system constraints. Ask what’s driving the way work flows, and who has the power to adjust it. Make trade-offs visible and shared.

Spot the Signs, Shape the Shift

Anti-patterns don’t mean your team is failing. They mean your team is learning. The most resilient teams are the ones that catch unhelpful habits early, and have the safety and support to try something else.

Retrospectives are the perfect place to surface them - as long as they’re structured for memory, not just reflection.

In the end, anti-patterns aren’t the enemy. Silence is.

Want to take action?

Try this in your next retro:

• Surface 1 anti-pattern the team has noticed (e.g. big stories, unfinished actions, silent standups).
• Ask: Why might this have emerged? What need did it originally serve?
• Run a one-sprint experiment to shift it. Keep it small.

The cost of anti-patterns isn’t just inefficiency. It’s losing the opportunity to get better, together.

Collaboration in large-scale organisations often reveals friction in places teams expect to run smoothly. As product and development functions scale, the number of moving parts increases. So does the risk of misalignment.

At Easy Agile, conversations with our customers frequently surface familiar challenges. While each organisation is unique, the core struggles of collaboration are shared. To protect the privacy of the teams we spoke to, we’ve anonymised all quotes. But every insight is real, direct from the people doing the work.

This post is for anyone navigating the complexity of scaled collaboration, whether you're leading a team or working within one. Sometimes the hardest part is seeing the problem clearly. These are the patterns teams are running into, the questions they’re wrestling with, and the cracks that emerge when planning, alignment, and communication break down. Understanding and acknowledging these issues is the first step toward solving them.

Here’s what teams are experiencing and the key questions they’re grappling with as they scale collaboration.

TL;DR – Common collaboration challenges in scale-ups and enterprises:

• Teams struggle with communication and alignment, especially when working across multiple teams or departments
• Managing cross-team dependencies is a significant challenge, often causing delays and requiring frequent coordination
• Capacity planning and skill allocation are difficult, particularly when teams have to balance project work with ongoing operational tasks
• Teams face challenges in breaking down work effectively and maintaining visibility of progress across different teams
• Frequent changes in priorities and scope creep disrupt team planning and execution
• There are difficulties in translating high-level strategy into actionable team priorities and objectives
• Teams struggle with effective retrospectives and continuous improvement processes

What breaks down in cross-team communication?

Communication challenges tend to intensify with scale. As soon as multiple teams are involved, misalignment becomes more likely. A Senior Product Manager from a global HR tech firm described a pattern many teams will recognise:

"One of the main themes I heard in conversations with leadership was the lack of process, transparency, visibility, and dependency tracking. It’s always been manual across teams. We’ve done a really good job, but there’s an opportunity to do better."

Another team member highlighted how this disconnect tends to grow over time:

"At the start of each quarter, our conversations are strategic and cross-functional, involving sales and strategy teams. But as we dive deeper into execution, communication shrinks down to daily engineering huddles, and essential alignment details often get lost."

The problem isn't a lack of communication, but rather a shift in its focus. When delivery takes centre stage, strategic context gets sidelined. When teams move into execution mode, that shift in communication cadence creates blind spots across departments, leading to confusion, duplicated work, or misaligned outputs.

Why is managing dependencies across teams so difficult?

Dependencies create friction when they aren’t visible or clearly owned. Coordination across teams can be derailed by unclear sequencing, late handovers, or competing timelines. An Agile Coach at a financial institution shared:

"We had to run bi-weekly cross-program dependency calls just to stay on top of what was blocking who. We just list dependencies manually, there isn’t any unified visibility. At the ART level, it’s a mix of RTEs, Scrum Masters, and team members trying to link things, but beyond that, it falls apart"

A delivery leader at a global credit bureau reinforced the limitations of existing tools:

"I’ve never successfully been able to really tackle dependency visualization and put a process around that. It's always been manual. When I'm speaking to an executive, that means something... But when I'm speaking to someone on an agile team, it changes as it rolls up...Without proper plugins, even a robust tool like Jira struggles to provide clear dependency visuals. Planning becomes complicated quickly, leaving teams stuck."

Dependency risk increases when shared work isn’t tracked or visualised in a way that’s accessible to all stakeholders. Teams need to see not just their own work, but how it connects with others. Teams need more than awareness - they need shared visibility, clarity on ownership, and consistent ways to plan around dependencies.

How do teams manage capacity when demands keep shifting?

Planning team capacity isn’t just about headcount, but also about competing demands. Teams are often asked to deliver roadmap initiatives while supporting legacy systems, resolving production issues, or addressing technical debt. A product leader from a cybersecurity company shared:

"We’re always trying to achieve a lot with limited resources, and it makes roadmapping really difficult. We’ve made progress in estimating the team's bandwidth more accurately by looking at what they actually delivered last quarter. But we still hit the same issue - too many topics, too little time."

Another team shared how they introduced tighter prioritisation controls using a third-party tool, but even rigid structures have their limits:

"We use XXX as a source of truth for prioritisation. We have around 80 different initiatives prioritised from 1 to 80 of importance... no meeting can be scheduled if the project is not approved in the tool."

This helped formalise approvals and reduce noise, but it also revealed a deeper issue. Even with a strict gating process, the volume of initiatives stayed high, and prioritisation alone couldn’t solve for limited capacity. Clearer structures don’t automatically reduce the demand on teams or ease delivery expectations. That tension persists unless strategic scope is also narrowed.

What makes work breakdown and visibility so hard to maintain?

Breaking down initiatives into independent, testable stories is not always straightforward, especially when scope is uncertain or spans months. A software engineer working across multiple teams explained:

"Breaking work down is hard - some teams still think in layers. They say, ‘This only delivers value when the whole thing’s done.’ On top of that, we often run big planning in a five-hour day or stretch it awkwardly over two days. Third parties and shared services don’t get folded into teams, which makes breakdown and clarity harder."

Large epics often outlive the context in which they were created. As scope evolves, teams may struggle to maintain clear acceptance criteria and shared understanding.

An Agile Coach reinforced how hard it is to keep sight of progress:

"We break each story into smaller pieces as much as possible where it's testable by itself so the testing team can test it... But if it’s a lengthy project, spanning more than two months, it’s easy to lose clarity and effectiveness...Consistently tracking actions across multiple sprints involves endless toggling. It's difficult to quickly understand what's truly improving and what’s still stuck."

As work grows more complex, clarity suffers. Without reliable visibility, work risks stalling or repeating unnecessarily. Teams need tools, systems, and shared language to ensure breakdowns don’t get lost in the shuffle and progress remains meaningful.

Why do changing priorities and scope creep derail plans?

Frequent priority changes and scope creep disrupt planning discipline. They often signal deeper issues: vague goals, shifting leadership expectations, or unclear ownership. One product leader summed it up:

"Priorities used to switch constantly - sometimes halfway through a project, we’d have 30% done and then get pulled into something else. That context-switching really hurts. It demoralises engineers who were already deep into a feature. We had to raise it in a full engineering and product retrospective just to get some stability."

Another shared the toll it takes on delivery teams:

"We often found ourselves mid-quarter pivoting to newly emerging business needs, without fully aligning on what gets dropped. That lack of clarity meant engineers felt whiplash, and team goals kept shifting."

Without stable anchors in the form of clear goals and boundaries, even well-planned work can unravel. Work, then, expands to fill the available sprint, regardless of long-term impact, which brings us to the next challenge.

What stops teams from aligning strategy to daily work?

Teams need clear goals. But clarity breaks down when strategic objectives are too broad or when every team interprets them differently. A senior product manager explained:

"Prioritisation is only as good as your strategy, and ours wasn’t clear. The business goal was just ‘grow revenue,’ but what does that mean? Acquisition? Retention? Everyone wrote their own product objectives. It became a bit of a free-for-all. When goals are vague, it’s hard to prioritise work that ladders up to anything concrete."

Another added:

"We all set objectives tied to broad company goals, but when those goals lack precision, our objectives become misaligned, making prioritisation difficult and often inconsistent."

Without alignment between leadership priorities and team-level execution, valuable work can feel directionless. Objectives become outputs rather than outcomes.

What holds back meaningful retrospectives?

Retrospectives are intended to surface learning. But without consistent follow-through, they risk becoming routine. One Agile Coach shared how to keep them practical:

"We’ve tried tools where you just send a link and everyone rates how hard it was to get something done. But too often, it ends up with one person speaking and everyone else just agreeing. We’re trying to avoid the loudest voice dominating the retro. It’s still a challenge to get real, reflective conversations."

Another shared the risk of retro fatigue:

"To track action items consistently isn't easy... I have to toggle down and look at each one, which can make things cumbersome when ensuring certain behaviours have stuck...Effective retrospectives should surface recurring issues, not just review the recent past. Discussing ongoing challenges helps teams proactively tackle problems and move forward."

The barrier is rarely the ceremony - it’s the follow-up. Teams need lightweight ways to track retro actions, validate changes, and revisit unresolved pain points.

Where to focus

Improving collaboration means addressing the systems and habits that hold teams back:

• Keep strategic conversations active, not just at quarterly planning.
• Visualise and track cross-team dependencies clearly.
• Protect capacity for both roadmap work and operational stability.
• Break work into testable, clearly defined pieces.
• Reinforce the connection between business goals and delivery priorities.
• Make retrospective actions visible and measurable.

The teams we speak to aren’t struggling because they lack process. They’re navigating complexity. The opportunity lies in simplifying where it matters and supporting teams with the clarity to make progress, together.

The first step is recognising these patterns and giving them language. When teams can see and name the problem, they’re already on the path to solving it.

How Easy Agile can help

Whether you're dealing with blurred dependencies, vague objectives or sprint volatility, Easy Agile offers three purpose-built solutions to help teams stay aligned:

• Easy Agile Programs brings structure and visibility to cross-team planning in Jira. Perfect for managing dependencies and long-range planning across multiple teams and projects.
• Easy Agile Roadmaps gives every team a simple, shared timeline view, so they can prioritise and sequence work with strategic context.
• Easy Agile TeamRhythm makes sprint planning, story mapping, and retrospectives more engaging and purposeful, turning agile ceremonies into actionable, team-owned progress.

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.