When estimating with story points should developers and QA provide their estimate based on their individual idea of complexity?

Question

The question was as follows (and from the QA member of the team): Should I think about how complex it is from a QA AND a developer's perspective? Or just from a QA's perspective?

Since story points account for effort + complexity my answer was that QA should provide an SP estimate based on their own understanding of how much effort it will take them as an individual. Especially since there's no way QA could know what the dev effort consist of and vice versa. Then, once everyone gave their estimates, we talked about the reasoning behind each person's estimate and rounded up to the highest estimate if there were differing responses.

Another related question: Should I think about the effort for just my work or the effort it would take for the story to be moved from in progress to done? For this one I also said that it should take into account just your piece of the overall dev effort. The combined and rounded up number will then capture the relative amount of time it will take something to move from in progress to done.

I wasn’t quite happy with my responses and want to see if anyone else out there has had similar questions from their teams.

Thanks!

Answer 1

A healthy conversation when estimating might go something like this:

Developer: "This is pretty simple, so I think it is a 3 point story."

QA: "I'm thinking about how we will test this story. It looks tricky to me."

Developer: "Talk me through your thinking on this please."

[technical discussion]

Developer: "OK, now I understand the story is more difficult than I first thought. How about we make it a 5 instead?"

Sometimes it may be the developer trying to convince the QA to change their estimate or any combination of team members doing this. The key is for the team as a whole to get an understanding of the overall challenge of the story and then estimate accordingly.

Answer 2

1) There are 3 factors you need to consider when estimating with story points:

• Complexity
• Uncertainty
• Effort

And it's shouldn't be just from your perspective (Be it QA or dev), your estimate should take into account both those areas.

Especially since there's no way QA could know what the dev effort consist of and vice versa.

Which is why scrum emphasizes on teams being cross-functional. This doesn't mean that every member of the team should be able to perform development, testing, designing, etc with equal proficiency but the team members are expected to have T shaped skills. The verticle bar of the T is your area of expertise and the horizontal bar represents the ability to collaborate with experts and apply knowledge in areas of expertise other than one's own.

But of course, most team members do not have T shaped skills when they start out. With cross-functional teams scrum helps teams get there and get there quicker. And the effects will be seen during the estimation where the team members would be able to better understand each other's perspectives on the work items being discussed.

2) You'd always want to estimate to get the task meet your "Definition of Done" as every work item in the sprint backlog is fully owned by the development team until it is "Done".

Answer 3

• If there are different opinions on the complexity and therefore estimate for a story, discussion and some resolution/consensus mechanism is needed. Converging on the higher estimate is one possible approach that likely reduces risk, but of course you should first establish whether the high estimate is based on a misunderstanding of the task or on some consideration that other team members weren't aware of.
• Estimates should always cover the whole complexity of a task, not just my part, otherwise you can't meaningfully compare estimates done by different team members. This requires each team member to not only look at her own part but at the expected effort of the team as a whole, which is a Good Thing anyway.

By the way, you probably shouldn't do math with story points, except for adding them up to check whether you're within your sprint capacity. Estimates are already rounded, too much granularity leads to an accumulation of rounding errors and increased uncertainty.