Development vs QA Estiomates

Last post 10:38 am April 4, 2020
by Sanjeev Nanda
7 replies
02:29 pm March 26, 2020


I really appreciate someone's input on the following situation.

Personally i do not believe this is a Unique situation and someone else faced the same challenge before.

Our sprints are 2 weeks and we have 3 Developers and 1 QA on the team.

So the challenge is that in most cases our story has number of points  estimates  has more points for QA vs what has developed estimated.

We do not use relative estimation. We do not use hours. Just points.


Story is estimate by Development is 2 points of effort estimation.

Story is estimate by Development is 8 points of effort estimation.

So most often Development team completes the story sooner and end up helping testing. And the Sprint doesn't get a spillage.

However When the story takes just 2 points to develop, it is possible to break it down to 2 stories.

So each story will be 1 point for development and 4 point for QA.

But some time the change has no breakable situation, not by code logic or otherwise.

Looking for a better solution to the issue described above.

Thank you


04:22 pm March 26, 2020

Personally i do not believe this is a Unique situation and someone else faced the same challenge before.

Correct. Why are team members unable to estimate as a team and demonstrate teamwork? That is the problem which ought to be solved. It isn't a matter of finding the right arithmetic.

06:39 pm March 26, 2020

Good Day Ian

I understand your point.

However effort made by developers to code is specific and effort made by QA is also specific.

Development 2 points and QA 9 points.

The total number of effort estimation points for the Scrum Team is 9.

Also developers do help testing to make the sprint.

Thank you


10:07 pm March 26, 2020

+1 to @ Ian Mitchell.  Scrum does not recognize titles in a Development Team.  The entire Development Team owns the work to turn a backlog item into an increment.  So why are things being double pointed based on activity?  Seems like a lot of work for no benefit. 

11:12 am March 27, 2020

Thank you @Daniel Wilhite - i think my brain is split now.

I would like to say i do understand the principal. However can you provide a much needed recommendation.

This is a very tough situation. Here is why.

The management asks why does it take 9 points for a team to complete the story. Why is it take so much effort.

They say - let's look into the effort in details and ask this question: "Coders/Developers - is your effort to code this change takes roughly 9 points"?. Developers answer - No, just coding takes us 2 points.

Next Manager asks QA analyst: "Does it take you 9 points to validate this story"? and QA says - correct, yes.

And when i am trying to explain that it is normal and it is a team matter how they accomplish the completion of DONE of this story including effort estimation, i'm being told i do not understand SCRUM and it cannot be such a difference in effort between Developers and QA.

So i really looking forward for some help here.

Thank you very much!


06:27 pm March 27, 2020

we have exactly the same issue. I'd appreciate if any one could provide some real-world experience of how you doing in your work

09:21 am April 3, 2020

Story point estimate is a very fluid thing. If management pressurises employees to give lower estimates, how can you still have realistic estimates and a realistic view of how log it is going to take? They'll just poker lower estimates, but that'll just hurt velocity. Ask management what they actually want to achieve and aim for that and try to stop the level of detail management works on.

Meanwhile, work with your team to have an agreement on the estimates instead of just an average. A story is only done when it is done, and not splittable in phases of "development" and "QA". In theory, the QA shouldn't always be the one testing it, right? The more flexibility you have on that part, the easier it is to adept to changing circumstances (what do you do if your QA calls in sick?) Try to encourage the team to poker the entire story, not just the part that they'll work on, so that they also learn to understand the work of the other activity within the team.

10:38 am April 4, 2020

Giving blank estimates to subordinates seems like a low thing to do. There is a particular flow that does on about these things. Rushing it either way, for the positives, or otherwise, seems unchecked as a practice - as someone should look into it in due course.

~Sanjeev Nanda