How can developers and testers agree on story point estimates?

Question

Previously we used duration for each story, but in our current sprint we are using story points (effort) keeping test team effort separate from the development team effort. Story points are based on complexity, effort, and doubt. These three points will differ for a developer/programmer than with someone creating manual tests or someone creating automated tests. How can all of these different factors be combined to created an overall story point estimate?

According to Scrum these should be combined (as it's a team effort), but how is this done? Is it just combining the developers' and testers' efforts, or do testers and developers have to estimate the combined effort? If the latter, are there guidelines for this to work effectively?

Answer 1

TL; DR

Story points represent consensus within the team. The goal of estimating story points is not to provide the largest or smallest estimate, but to accurately reflect the effort required by the entire team to meet the "definition of done."

Lewis Carroll Does Scrum

Consider a story like:

As a practitioner of Extreme Dentistry,
I want to know how many teeth the average Jabberwock has
so that I can hire enough dental hygienists.

During a round of planning poker, the programmers on the team might estimate this story at only two points, since adding a tooth-count column to a database table is a minor change for them. However, the testers might estimate this story at 13 points, since getting close enough to count a Jabberwock's teeth to gather accurate fixture data is a dangerous (and potentially fatal) task.

Should the story be two points, or thirteen? That's up to the team. Maybe the whole story is really 13 points overall, or the team discusses it and realizes that the story really ought to be 21 points once they factor in the need for an emergency medical team to be kept on standby. Then again, perhaps the team decides to reduce uncertainty by switching in a five-point Vorpal Sword story as a prerequisite, which reduces the Jabberwock story to only eight points in the next sprint.

Getting Consensus

Sometimes getting consensus is hard. That's why planning poker uses time-boxing, so that consensus-building doesn't take infinite time. Remember, you can also call on the Product Owner to clarify stories, decompose stories, or swap out stories for something else on the Product Backlog. Some level of consensus should always be possible.

If a story is accepted into the sprint, at the end of the time box the team must record an estimate. This estimate may be:

1. The average (or mean) of the estimates.
2. The median of the estimates.
3. The worst-case estimate.
4. The best-case estimate (but please don't do that).

Failure to estimate properly will become obvious during the sprint, and will provide good grist for the mill during your next retrospective. Continuous process improvement is the name of the game, after all.

Answer 2

The team should come to a consensus on the combined effort

You want to work towards the ideal of a cross-functional team and the team owning all the stories rather than individuals. While that is a long term goal, you want to look for practical steps you can take to resolve these issues in the meantime.

To answer your question, the team should come to a consensus on the combined effort. As CodeGnome suggested, start planning poker sessions for estimation, if you are not already doing so. Let each team member understand the scope of work and come up with their own estimate, without being influenced by others. The discussion that follows should focus on the reasons for the lower or higher estimate. That will foster a better understanding of the development and testing work content across the team. We have also seen some misunderstandings get clarified. For example, the developers might point out that they will be messing with the base classes and that might warrant a wider range of regression tests than what the testers planned.

Answer 3

I am in similar situation with a team of DEV & TEST people. After several Sprints, we have agreed to have a norm for "Normal stories" that Dev/ Test effort ratio is ~ 2:1 (= current team structure with 6 DEV & 3 Test)

We are not really converting Story Points to hours but we built a common sense to forecast Dev & Test effort based on Story Points (let's say ~2 days DEV & 1 day Test for a 3 points story)

Then, for abnormal stories that might require significant more efforts for DEV or TEST, We allow that specialty to make decision on story points (after a while, we see a pattern that more DEV effort tickets relate to Engineering task for set up, investigate, discover new things; more Test effort tickets relate to manual regression of Done stories after big refactor/ business rule changes)

I know we are far from Ideal Agile/ Scrum but trying the best to operate with current team structure, skills & still delivering Value to Product, end users.

Answer 4

There are a few reasons for estimating:

• To work out how much the team can commit to doing, each Sprint, in order to manage stakeholder expectations
• To plan releases based on how much work the team can do
• To see if there are any discrepancies in understanding of the work that needs doing.

With respect to the discrepancies, there are plenty of other ways to uncover this without estimating. I like to use Behavior-Driven Development's scenarios in conversation for this; if you can decide which scenarios are in and out of scope, and ask questions designed to find missing or unclear scenarios, you'll usually find out if there are misunderstandings or work that could be descoped for another story.

With respect to how much the team can do, and planning releases, you can think of the team as a pipeline. At any point, there will be one role whose time is constrained, and which represents the narrowest part of the pipe. By considering how fast that constrained role can work, you can see how fast the work can flow through the system.

It's usually the case that developers can help overworked testers, but testers can't always help developers as easily. For that reason, frequently developers are the constrained role, and if that's the case in your team then I would suggest worrying about the development effort rather than the test effort. Including complexity and doubt in the estimate is a great idea. If the constraint ever moves away from the developers, you can change the role that does the estimation.

It's still worth talking through the test effort as this may impact how much work will fall to the devs. Note that developers and testers have very different mindsets, even when their skills are similar, so while they can collaborate effectively it's not always the case that they can take on each other's roles with flexibility.

As a final note, story points are meant to be a lightweight way of planning and setting expectations. Teams that worry too much about accuracy tend to inflate stories so that points become worth less and less, and there are more of them, and also tend to spend more time on their process when they could actually be getting work done.

For this reason I prefer Kanban, which makes the constraints in flow very apparent and explicit, while providing more flexibility than Scrum's sprint cycle. Cumulative Flow Diagrams are also a great way of spotting constraints in either framework.

Answer 5

Testers should take part in story sizing and complement the development team. A discripancy between sizes is natural in few cases (Dev saying 3 and QA saying 5) a 2 and 13 hardly occurs.