Development vs QA Estiomates

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.

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

Andrew

+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. 

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!

Andrew

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

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.

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

You can come to an agreement with your team according to the past experiences.

We used to have that problem where QA used to allocate more points than they actually where working.



Allow me to elaborate: 

• Let's say Dev team estimates 5 points for a specific user story
• QA estimates 6 points for the same user story.

At the beginning we used to do a quick sum Dev + QA = 11 points. 

Using Fibonacci sequence (1,2,3,5,8,13) that means our user story was 13 points (being 13 our maximum) so we need to split the user story in 2 different smaller portions; let's call them userStoryPart1 and userStoryPart2.



But then we realized Dev team estimated both user stories correctly and QA at the end of both user stories they had some "buffer" time.  That's exactly when we knew we could do our estimations better.



Then we encouraged the team to estimate the user stories not as Dev + QA  but as a whole team.  Also, reviewing past iterations and completed user stories we came to an standard for the future. If we said userStory2020A was a 3 pointer, then all the similar user stories should be around 3 points, maybe 2 or maybe 5 but never more or less than that range. If we agreed userStory2020B was a 5 pointer, a similar one should be around 3 or 8 points but never out of that range. 

I have included our estimation agreement for the past year. When we think we need to change it then we have a meeting to talk about it.

Hope this helps.



 

Using agreement to force the team to estimate "similar" stories similarly might be not the best possible option. After all, there is a multitude of factors aside from the size of the story that affects estimation. Even the same story may become more "expensive" few sprints later, for example, due to evolved DoD or accumulated debt (especially considering that forced estimations usually end up with debt accumulation).

Why should we force the team to commit to artificial (aka "similar") estimation instead of delegating estimation to those who know the best? After all, too many efforts for not so valuable PBI might be a good sign that the item is not worth these efforts... 



Oh, I know some teams might abuse this trust. But having the courage to recall "too expensive" items would promote team self-management way better than externally enforced agreement. 

It sounds like management may need some "training" on how to support their teams rather than adjusting their teams. I wrote an article on this that may be helpful, maybe not. https://sdtimes.com/agile/guest-view-dont-use-velocity-as-a-weapon/

In the end it does not matter at all what the team estimates the story to be as it is relative to them and their work, past and future.  So they could make it a 3 and then it is a 3, but also then it means things that were a 3 are a 2 or 1, etc. and now the estimated effort for a 1, 2, 3... is different than what it was before and nothing changes other than the number.