Best Practice for Estimation in Agile Teams (Story Points vs. Other Methods)

[Afrooz Kasraei]

Hi Community,

We are a software development team including frontend, backend, and mobile developers.
Currently, we are using story points for estimation, but I’m still not sure if this is the most effective approach for our team.

I’d like to hear your experiences and recommendations:

• What is the best practice for estimation in Agile teams?

• Should we continue with story points (using baselines and relative estimation), or are there other methods (e.g., T-shirt sizing, no estimation, hours) that you have found more useful?

• How do you ensure consistency and fairness across different roles in the team when estimating?

Any advice, best practices, or references would be greatly appreciated. 🙏

Thank you so much for your attention and participation.
Afrooz

[Bert Dombrecht]

Hi Afrooz,

Over the years, we have experimented with both story points and hours estimation in our team. And we have different teams on our Jira site, all using a different estimation field (story points, T-Shirt sizes, man days, hours, ...)

In our team we first estimate our epics roughly (weeks/days or T-Shirt sizes). At this stage, story points could also work as it is a flexible and relative estimate.

However, when planning our sprints we typically estimate our work more accurately. We do this together as a team (in days/hours). For each sprint, we review the workload vs. our resource capacity. Our developers also log their time spent. Story points proved to be too abstract for us, especially when communicating to our business teams. We even found ourselves trying to 'translate' story points into hours (a sure sign that story points was not for us :-) ).

We are mindful about the pitfalls of hour-based estimation, such as emotional attachments to timelines and potential blame if estimates are missed. To avoid these we have regular standup meetings, sprint reviews and retrospectives to review and adjust the planning with an agile mindset.

In conclusion, I wouldn't say there's a best practice overall though, this is just the best fit for our team and team culture. I would suggest you try different approaches and go with what feels best for your team. Ultimately, the process should work for you and not the other way around.

Kind regards,

Bert.

[Iryna Komarnitska_SaaSJet_]

Hi @Afrooz Kasraei ,

Here’s the quick version that’s worked well for mixed FE/BE/mobile teams:

Pick the method that matches your work:

• Story points → best when complexity varies. Keep it simple: Fibonacci, 3–5 reference stories, and quick calibration in refinement.

• Issue count → great if items are similarly sized. Pair with cycle time and enforce a clear “split until small” rule.

• Original time estimate → use when you have firm deadlines, billing, or contracts. Track est. vs. actual and adjust.

In this article you can find more information. Hope it will be helpful for you!

[Mary from Planyway]

Hi Afrooz,

There's no one-size-fits-all answer, but let's break down some best practices and explore your options.

What is the best practice for estimation in Agile teams?

The "best" practice often revolves around understanding the purpose of estimation. In Agile, estimation isn't about setting rigid deadlines months in advance; it's about:

1. Forecasting: Helping the team and stakeholders understand how much work can be accomplished in an iteration or release.
2. Prioritization: Informing product owners about the relative effort of different features to make informed prioritization decisions.
3. Capacity Planning: Assisting the team in committing to a realistic amount of work for a sprint.
4. Identifying Complexity: The estimation process itself can uncover hidden complexities and facilitate valuable discussions.

The emphasis should always be on relative estimation and team collaboration, rather than individual accuracy.

Should we continue with story points, or are there other methods?

Let's look at the pros and cons of different methods:

1. Story Points (Baselines & Relative Estimation) - Continue if you can refine them!

• Pros:
  • Abstract & Relative: They abstract away from time, focusing on complexity, effort, and uncertainty, which is often more accurate than time-based estimates.
  • Encourages Discussion: The process of reaching consensus on story points forces team members to discuss the work, uncover assumptions, and understand dependencies.
  • Stable Velocity: Over time, a team's velocity (story points completed per sprint) can become a reliable metric for forecasting.
  • Roles Agnostic: A story point represents the effort for the entire team to complete the story, not just one role.
• Cons:
  • Can be Mistaken for Hours: Teams often struggle to decouple story points from time, leading to internal conversion.
  • Initial Calibration: Establishing a baseline (what is a "1" or "2" point story?) can be challenging and requires consistent effort.
  • Consistency Issues: Without clear guidelines, different team members might assign points based on different criteria.

2. T-Shirt Sizing (S, M, L, XL)

• Pros:
  • Even More Abstract: Excellent for early-stage estimation or very large initiatives where granular detail isn't needed.
  • Faster: Quicker than story points for a large backlog.
  • Focus on Relative Size: Clearly emphasizes the relative difference between items.
• Cons:
  • Less Granular: Harder to use for sprint-level planning where more precision is helpful.
  • Conversion to Velocity: Can be more complex to track a consistent "velocity" for capacity planning without a numerical equivalent.

3. No Estimation (NoEstimates)

• Pros:
  • Focus on Flow & Delivery: Shifts focus entirely to delivering value and reducing work in progress.
  • Reduces Overhead: Eliminates the time spent on estimation meetings.
  • Suitable for Mature Teams: Works best for teams with stable flow, small, well-defined stories, and a good understanding of their domain.
• Cons:
  • Difficult for Forecasting: Can be challenging for stakeholders who need even rough timelines or budget projections.
  • Requires Small Stories: Relies heavily on breaking down work into very small, consistently sized chunks.
  • Requires High Trust: Stakeholders need a high degree of trust in the team's ability to deliver.

4. Hours/Days Estimation

• Pros:
  • Familiar: Many people (especially stakeholders) are accustomed to time-based estimates.
  • Direct & Understandable: Seems straightforward to grasp.
• Cons:
  • Highly Inaccurate: Humans are notoriously bad at estimating complex work in time, especially when uncertainty is high.
  • Penalizes Efficiency: Faster developers might be "punished" by being assigned more work because they estimate lower hours.
  • Ignores Complexity & Uncertainty: Focuses solely on duration, not the inherent difficulty or unknowns.
  • Can Lead to Micro-Management: Focus can shift to tracking individual hours rather than delivering value.

Recommendation:

Given you're already using story points, I'd recommend sticking with them but focusing on improving your process. Story points, when used correctly, are generally considered the best practice for typical Agile teams because they balance the need for forecasting with the inherent uncertainty of software development.

If you find story points are consistently problematic, consider T-shirt sizing for higher-level planning (e.g., epic estimation) and then breaking down into smaller stories for sprint planning, which can still use story points, or even moving towards a "no estimates" approach for sprint-level work if your stories are consistently small and well-understood.

How do you ensure consistency and fairness across different roles in the team when estimating?

This is crucial for the success of story points!

1. Cross-Functional Estimation (Whole Team):
   • All Roles Participate: Frontend, backend, mobile, QA, and even product owners/designers (if they understand the technical implications) should be part of the estimation session.
   • Focus on "Done": The story point represents the effort for the entire team to get the story to "Done" (meeting your Definition of Done). This includes development, testing, deployment, etc.
   • Planyway can help here! Use Planyway's task management features to ensure all tasks (FE, BE, Mobile, QA) related to a story are visible and considered during estimation. You can even visualize dependencies.
2. Clear Baseline and Reference Stories:
   • Establish a "1-Point Story": Define what a "1-point" story looks like for your team. This should be a small, well-understood task with minimal complexity and uncertainty. Use it as a constant reference.
   • Reference Stories: Keep a few "reference stories" (e.g., a typical 2-point, 5-point, 8-point story) that the team can refer back to when estimating new items.
   • Regular Review: Periodically review these reference stories as your team's understanding and capabilities evolve.
3. Planning Poker:
   • Simultaneous Reveal: Everyone estimates silently (e.g., using physical cards or an online tool) and reveals their estimate simultaneously. This prevents anchoring bias (where the first estimate influences others).
   • Discussion for Discrepancies: If there are significant differences in estimates, the high and low estimators explain their reasoning. This uncovers hidden complexities, misunderstandings, or different approaches, leading to a more robust estimate.
   • Focus on Learning: The goal isn't to force everyone to agree instantly, but to learn from different perspectives and refine the team's understanding.
4. Definition of Done (DoD) & Definition of Ready (DoR):
   • Robust DoD: A clear DoD ensures everyone understands what "done" means for a story, preventing underestimation due to overlooked tasks (e.g., "Oh, I forgot we need to write documentation for that").
   • Clear DoR: A clear DoR (e.g., stories must be clear, testable, and have acceptance criteria) ensures stories are well-understood before estimation, reducing uncertainty.
5. Focus on Team-Level, Not Individual, Velocity:
   • Shared Responsibility: Emphasize that story points are a team estimate, and the velocity is a team metric. Avoid tracking individual contributions by story points, as this can lead to gaming the system or an unhealthy focus on individual "output."
6. Continuous Improvement & Retrospectives:
   • Inspect & Adapt: Regularly discuss in retrospectives how estimation is going. Are estimates consistently off? Why? Are there specific types of stories that are harder to estimate?
   • Adjust Process: Be willing to adapt your estimation process based on what you learn.

Planyway as a Tool for Estimation & Planning

Planyway can be a fantastic complement to your estimation process, especially when integrated with Jira (assuming you use it).

• Visualizing Workload & Capacity: After estimation, you can drag and drop your estimated stories onto the timeline view. This allows you to visually see your team's capacity and workload for upcoming sprints or iterations.
• Tracking Progress Against Estimates: As tasks are completed, you can see how your actual progress aligns with your initial estimates. This provides valuable data for your retrospectives to refine future estimations.
• Team-Wide Visibility: Everyone on the team can see the estimated work, who is assigned what (if you use assignments for tasks within a story), and the overall plan, fostering transparency.
• Roadmapping: Use the timeline and story point data to create more accurate long-term roadmaps and release plans for stakeholders.

In summary:

• Stick with Story Points but invest in refining your process.
• Emphasize Team-Wide Estimation with all roles contributing.
• Use Planning Poker to facilitate discussion and uncover complexity.
• Establish Clear Baselines and Reference Stories.
• Leverage Planyway for visual planning, capacity management, and tracking progress against your estimates.

I hope this helps your team move forward with confidence!

[David Nickell]

It may seem counter intuitve, but to save all the good reporting that goes with Story Points, you can treat them like days or even 1/2 days.

Imagine a 2 week Sprint -- people are expected to allocate 2-3 days each Sprint on "Shoulder taps", "triage" and all that unplanned stuff.

So everyone starts with 8 Story Points capacity.   Off for 2 days?  You're down to 6....

Then in estimating, if you honor the Fibonacci sequence, your estimations are 1 (A day or less), 3 (More than 1 day but less than a week), etc.  No stories over 10 points please :-) 

Over time if you use components correctly -- you will start developing pretty accurate estimates when building your roadmap.  for example, "the last time we modified component X,  We recorded 20 hours against the EPIC. So Mr Product Owner, which 3 Story Point project can we drop to fit you in?".

And Post Sprint -- it's pretty easy to reconcile the SP velocity.

Hopefully this make some sense whether or not there are any guidelines or textbooks that support this concept.