Right way of Estimations
I joined a new project and the team is assigning SP values in this way. They take Dev estimates separately (say 5) and QA estimates separately (say 3). Now, they assign the story with 8 SP value. Similarly with other stories too, and thus come up with good number of velocity every sprint. Does it seem fine? How can it be corrected without impacting the velocity? Please help.
If all of the Developers have agreed that this is the best way to do their estimations, and they see that it is working for them, then there is nothing that needs to be done as the team has come up with a working method of providing forecasts for each sprint.
If the Developers -- including those doing QA -- are estimating well, what problem are you trying to solve?
Do you have any concerns about how effectively teamwork is being demonstrated during the Sprint?
What do you mean with:
thus come up with good number of velocity every sprint.
Velocity should at most be internal scrum team metric that helps with PBI selection during sprint planning.
My question is what is the problem? What is good number of velocity you refer to?
Is the sprint goal being met every sprint?
The purpose of estimation, especially in a Scrum context, is to allow the team to determine a reasonable number of Product Backlog Items to be selected for a Sprint. Based on the way you are estimating today, is the team able to achieve the goals of Sprint Planning successfully? Can the team craft a Sprint Goal that is achievable during the Sprint and select an appropriate number of Product Backlog Items? If so, then there's nothing wrong with the way that you are estimating. If the team is struggling, then the estimates could be one thing to look at but may not be the only thing to look at.
Going to join the bandwagon.
Does it seem fine? How can it be corrected without impacting the velocity?
Does the team think it seems fine? And why do you think it needs to be corrected? Is there a problem that you are trying to solve other than having them estimate in a way that you choose?
The riska as you can also see here is we are strengthening the functional boundaries between QA and Dev. you may ask can QA achieve 3 points of work if dev has not done their 5 and reverse is also true so, I hope the work only gets done when both of them do it. The idea is we compare based on overall size.
Agree with what others have mentioned above...If it works for the team and it generates good conversations, what is there to correct?
Atul raises a good point around watching for functional boundaries being established within what should be Developers. This approach may imply that there is division and/or handoff between Dev and QA which could be something to discuss with the team.