Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Right way of Estimations

Last post 10:55 am June 20, 2021 by Ryan Kent
7 replies
11:25 am June 17, 2021

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.

11:39 am June 17, 2021

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.

11:46 am June 17, 2021

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?

12:03 pm June 17, 2021

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? 


12:36 pm June 17, 2021

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.

02:54 pm June 17, 2021

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?

06:45 am June 20, 2021

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.


10:55 am June 20, 2021

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.