Skip to main content

Story point estimations

Last post 10:23 pm January 20, 2021 by Daniel Wilhite
4 replies
09:01 pm January 19, 2021

Hello everyone, 

The team is transitioning to story point estimations from hourly estimations. While giving story points to the story (given we have  backend story), is it best to give a combined point that will include the complexity of backend implementation + QA testing ( 8 point out of which 5 is for backend implementation and 3 for testing) or for QA open another task and link to the story thus QA’s will provide their estimate independently? I assume this contradicts to the fact that while development is done but testing is not, so value is nor provided. But on the other hand team might have cases where development is done but some of the stories are not tested till the end of the sprint  

I would like to know your opinion on this matter. 

09:16 pm January 19, 2021

Assuming that the "stories" you refer to are Product Backlog items, are you sure that each one is valuable to the Product Owner? Remember that he or she must be able to order them so value is maximized. I'd suggest that this consideration ought to be addressed before deciding on an estimation method.

09:30 pm January 19, 2021

This is an old problem with a beard 😉 I can recommend you to check i.e. this blog:

Splitting "stories" by competencies and estimating it separately is pointless, as well as the end estimate is also in most cases. Keep "stories" as stakeholders/users needs or problems to address and think about how difficult it may be to come up with a solution, how confident you are about what is known (and unknown), how many people and/or 3rd parties will need to collaborate, is it something similar to what we had done in the past, etc.

You can also think about story points as a scale of confidence: How confident (as a team) we are that this PBI is well refined and can be considered to tackle within one sprint? [the higher the number, the less confidence we have]

If you focus on splitting "stories" by competencies, it is an easy road to siloses, and to teams within a team that lags behind each other (mostly "QA"). Also if you keep the story as a whole, but split the estimation per competency, it is an easy way to not think about what needs to be done as a team, but only "what I need to do" - it is not very helpful in the long run.

The value of estimating is in the process, in mutually understanding what is needed and in a different point of view, not in the number in the end - that often is wrong. Value more discussion over the number that pops in the end, and you will be good to go IMHO.

03:59 pm January 20, 2021

Think about when a story is done for the team and estimate for the story what is necessary to get the story done. Splitting it up to dev and qa will bringt you in a situation that some stakeholder expect PBIs are finished but they aren't. You don't want have this situation. I had this experience when I was a test automation engineer and after some time the test automation was phased out of the stories and then partly ignored. After again some time we run into the problem that there was no test automation for exact these stories. And all was about splitting the stories into competencies.

10:23 pm January 20, 2021

The team is transitioning to story point estimations from hourly estimations.

Is there a specific reason why this is occurring?  Is there something that is trying to be solved by the change? If not, you might be doing work for no reason.

However, if you are doing it for a reason do not go down the path of splitting by competencies.  That will just get you into a lot of problems like the ones that have already been mentioned.  Story Points are meant to represent the estimate for completing the story.  And a story is a problem statement that needs to be solved in order to deliver value.  "Build a widget" and "test a widget" are not stand alone because the value is not recognized until both have been accomplished.  Also don't combine two estimates (a 5 for dev and a 3 for test).  Agree on a single estimate that represents all of the work needed by whoever will be involved.  Stop looking at things in silos and help your team look at how they can work together to accomplish goals as a 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.