How to Get Your Team to Consider Testing When Story Pointing: A QA’s Guide

In Agile teams, misaligned story point estimates happen frequently.

In a recent sprint planning session for an e-commerce application, my team faced significant estimation differences for a seemingly simple feature:

"As a user, I can filter products by price range."

The developer estimated 3 points, considering it a straightforward implementation using existing components. However, as a QA engineer, I estimated 8 points.

I identified several testing complexities the developer hadn't considered:

• Multiple browser and device compatibility testing requirements
• Edge cases like empty results and boundary values
• Performance testing under different load conditions
• Accessibility compliance for the filter UI
• Integration with other filtering mechanisms

This example illustrates why estimation discrepancies are natural and potentially valuable.

In my team’s case, we used this discrepancy as an opportunity to discuss testing requirements thoroughly, ultimately agreeing on 5 points after understanding each other's perspectives.

However, when not managed well, misaligned estimates could lead to missed deadlines, disappointed stakeholders, and team members who lose confidence in the planning process.

So, let’s discuss steps that you can take to align different perspectives on the estimate on your team using a practical example.

Practical QA Estimation Techniques: A Step-by-Step Guide

To demonstrate how QA engineers can improve estimation accuracy, let's walk through a practical example using a flight sorting feature. We'll apply a structured step-by-step approach to the user story, showing how breaking down testing activities leads to more realistic estimates.

User Story:

User Story: "As a traveler, I can sort flight prices from low to high."

Acceptance Criteria:

1. Flights should be sorted in ascending order by price
2. If no flights are available, display "Please search using different combinations"
3. If two flights have the same price, sort them alphabetically

Step 1: Break Down Testing Activities

First, break the story into discrete testing activities, and don’t assign points immediately. A breakdown could be:

• Functional testing of sort behavior (primary path)
• Validation of edge cases (empty results, identical prices)
• Cross-browser and device compatibility testing
• Regression testing of related functionality
• Potential automation requirements

This increases estimation accuracy by reducing the likelihood of missing critical testing activities.

Step 2: Assess Testing Complexity Factors

For each activity, evaluate the complexity factors that affect the estimation using questions.

• Data Requirements: Do we need to create specific test data with identical prices to test the alphabetical sorting?
• Environment Dependencies: Will we need to test across multiple environments or with specific backend configurations?
• Test Automation Potential: Can existing automation frameworks handle this, or will we need custom scripts?
• Regression Risk: Does this change affect critical paths in the application?

Evaluating complexity factors enables efficient resource allocation by identifying areas that require the most attention and could impact time.

Step 3: Apply Planning Poker Effectively

Planning Poker is a collaborative estimation technique used in Agile teams to predict the effort or complexity of user stories. Each team member selects a card (usually from a Fibonacci sequence) to represent their estimate, and all cards are revealed at the same time.

This encourages discussion, uncovers misunderstandings, and helps the team reach a shared understanding of the work involved. It involves:

1. Silent Assessment: After the story is presented, everyone silently considers their estimate

2. Simultaneous Reveal: All team members show their estimates at once to avoid anchoring bias

3. Explain Outliers: Those with the highest and lowest estimates explain their reasoning

4. QA Perspective Sharing: As a QA engineer, articulate testing considerations.

   "I estimated 5 points because we need to verify the sorting algorithm with various price combinations, test the empty state message, validate alphabetical sorting for identical prices, and ensure compatibility across our supported browsers and devices. We'll also need regression testing since the sorting mechanism affects multiple pages."

5. Convergence Discussion: The team discusses until reaching consensus or a reasonable compromise

Step 4: Translate to Time-Based Estimates (When Needed)

While Agile emphasizes story points over hours,  stakeholders sometimes need time estimates. Let’s break down the 5-point story into QA activities with time allocations:

• Writing test cases (1 hour): This allows time to thoroughly review the user story and define clear, structured test scenarios, ensuring full coverage of functional requirements.
• Testing against acceptance criteria (1 hour): Allocating an hour helps verify that all specified conditions are met and the feature behaves as expected under typical user flows.
• Cross-browser testing on four browsers (1 hour): Ensures the feature works consistently across major browsers (e.g., Chrome, Firefox, Safari, Edge); one hour is sufficient for a focused smoke test on each.
• Mobile testing on iOS and Android (1 hour): Covers basic compatibility and UI behavior on common mobile platforms, checking for layout issues, touch interactions, and responsiveness.
• Buffer for unforeseen issues (1 hour): Accounts for unexpected bugs, environment issues, or edge cases that can’t always be predicted during planning but often arise in real-world testing.

Total estimated QA effort: 5 hours

Combining Planning Poker with historical comparison is particularly effective.

When estimating the flight sorting feature, we referenced a previously completed 3-point story for filtering by airlines and a 5-point story for price range filters. This breakdown helps validate that the story point estimate is reasonable based on actual testing work required.

Our comparative approach grounded our estimate in actual delivery history rather than subjective opinions.

Don’t Aim for Perfect Estimates

The goal isn't perfect estimates, it's making sure your team sees the full scope of work before committing to deliver it.

Estimation accuracy improves when teams understand and value different perspectives, especially the QA viewpoint that often identifies hidden complexities and edge cases.

By breaking down stories into specific testing activities, assessing complexity factors, and using structured estimation techniques like Planning Poker, you can arrive at more realistic estimates that account for both development and testing efforts.

In your next sprint planning, try asking: "What's the riskiest or least understood part of this story from a QA perspective?"

This single question can surface hidden work early and drastically improve estimation accuracy.

References

• Planning Poker
• Software Testing - Estimation Techniques