Story point estimations
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.
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.
This is an old problem with a beard 😉 I can recommend you to check i.e. this blog: https://www.mountaingoatsoftware.com/search?keywords=story+points
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.
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.
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.