DEV & QA Story Point Total

Question

If dev thinks a story is 3 and QA says, it's a 5. You don't add them together to get 8, correct? I've always had the impression that whatever the consensus is, that's what the point value will be. Meaning, if the only person saying it's a 5 can't justify why, then the whole story including the QA testing would be a 3. I hope that makes sense.

Answer 1

Correct, although the really important part of this is the conversation:

"Hey QA, I thought this was a relatively simple story. I'm interested to hear why you think it is a 5"

As the team works together for a while you start to get the devs understanding more about the QA side and the QA's understanding more about the dev side.

Answer 2

Your method is correct. The whole idea is that if, in this example, the team later decides that 3 was an underestimate, they might say 5 the next time.

If you can keep ego or pride out of the estimates (there are no 'right' estimates; and in this example the QA person should not later gloat on 'being right it was 5'), then the team will get better at estimation and completing the sprint.

Treat it like a game: "Let's see if we can estimate everything so well, that we 'score' another sprint."

Answer 3

Within a Single Team

If dev thinks a story is 3 and QA says, it's a 5. You don't add them together to get 8, correct? (sic transit)

You tagged this "agile" but not with a specific framework. Based on that, let's start by assuming you have a single, cross-functional team with both developers and testers working collaboratively on the same team. In that case, the goal is to reach a consensus among the team members on the relative level-of-effort is for the whole team to complete the user story in a way that meets the Definition of Done. Since all members are on the same team, they are collectively responsible for completing the whole story, not just estimating sub-tasks parceled out to individuals. Each story, if properly decomposed using INVEST criteria, has a singular estimate for completion rather than representing the sum of multiple deliverables.

Since your developers think this story is easier to complete than your testers do, there's a conversation that needs to happen about the total level of effort involved. Perhaps the story is easy to code but hard to test, or the developers and testers may be over- or under-estimating based on unspoken assumptions about their own work or the work done by other members of the team. Regardless of the reason, it's an opportunity for them to talk together and plan how the work will be done and why it will be easier or harder to complete than someone else expects. They can then re-align their estimates based on the additional information.

If they still can't agree then the team can split the difference, or pick the high or low estimate. It doesn't really matter, as long as the team is consistent about it. Either way, over time the actual range of the team's velocity will converge based on the estimation technique employed. A small, one-off difference like this isn't really statistically significant over the life of a project or (in many cases) even within a single iteration.

With Multiple Teams

On the other hand, if developers are tossing code over the wall to QA, then you don't have a single user story. You actually have at least two, each with its own assumptions about what's involved and how hard it may be relative to other work. In that case, your estimates could potentially be additive, but story-point estimates are generally not comparable between teams. Some frameworks like SAFe gloss over this by treating story points as days as a way of "normalizing" estimates across teams. However, story points are a measure of relative effort, not a proxy for time, so SAFe's use of the term will likely lead you astray.

If you have multiple teams, you shouldn't just add the story points of related stories. Instead, you should let each team use its own story point estimates and then use the velocity of each team to try to estimate time if that's what you're really measuring anyway. If you're genuinely trying to estimate level-of-effort between two teams with different estimation baselines, then you could use velocity, cumulative flow, or some other metric to try to combine the estimates into a combined estimate within a given confidence interval.

At a more basic level, you could toss the whole paragraph above and just ask the two teams to estimate the story together as if they were on the same team. Then use that collaborative estimate in whatever form makes the most sense for the overall project. Since there's no substitute for communication, asking the teams to work together on a plan and a single probability-based estimate makes more sense than trying to convert dissimilar units anyway.

Conclusion

Regardless of your structure or technique, communication and collaboration are the key. If you don't have good communication and collaboration within the team or between teams, an "estimate" isn't even an educated guess; it's just a random number given based on insufficient information and lack of planning.

Facilitate the conversations, and help the teams work together on a common plan. As long as that happens, you'll either resolve the difference in estimates or make the difference irrelevant to successful delivery of the common product increment.

Answer 4

For me the story-point estimation process looks like this:

1. Everyone blindly estimates the whole story in points, including development, testing, releasing, fixes.
2. Differences are discussed shortly
3. Revote blindly
4. Decide on points

Now what todo when there is still a disagreement in points after the revote? I personally always just take the highest number. Because in your case the 3 might be a 3,5 and that only fits the 5 bucket. I like to see the points series as buckets, and take the one that surely fits the content.

On the short term I always try to under-promise and over-deliver, rounding up helps with this. I would only discuss points that differ more than one step on the scale, like 3 and 8. For a 3 and 5 I would just pick the 5 without any discussion, because it is faster and good enough.

Overall it does not really matter how you pick your final number, just try to be consistent over time. Also it depends on the goal of the points, predictability versus conversations.

Also be aware you are comparing estimates of essential complexity, but in reality it is accidental complexity that costs the most time and has the highest uncertainty. Therefor if you are researching Agile software development estimates please watch: 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development