Story pointing for different type of works
Assume a team consists of 2 backend, 2 frontend, 1 designer and 1 anaylist.
Scenario 1.
A team takes a story in which there is not a design sub-task included for this story. A designer should be participate in estimating story point which there is only technical works?
Scenario 2.
A team takes a story in which there are all the layer of works such as BE, FE, Designer and analyst. But Back-ender's part in this story is so small so he evaluates his work as 3, Frontender's part in this story is so huge so for him his work is about 34 and he will use all of his performance only this work and its applicable. How to get real point of the story in this situation? take average of all members points? But i think that Story Pointing is for to make a story clear for everyone in the same level. So if I am Backend developer I think that the work is so huge. But my peer other BE developer thinks that its not a huge as i think . Here is 2 options
1) I miss some point which make easy out story so we disscuss and find it and give the same number
2) My peer misses some point which make easy out story so we disscuss and find it and give the same number.
But How to estimate it if we have different works as Front end and Backend and my duty is so small, my peers duty is so huge. As i asked on Scenario 2. Thanks.
Do you believe the team's Developers ought to share accountability for these and all other estimates they make?
For scenario 1, you may wish to include pair-programming during the sprint for the designer and analyst so that they can gain knowledge in BE & FE. The BE's & FE's should also gain designer and analyst knowledge during a sprint where their workload isn't so high. Doing this will add redundancy to your team.
Remember, that whatever estimating method you choose to use, it's resulting estimate will always be wrong, due to continuous investigation of each PBI during the sprint.
From how I understand it, story points should never be used as performance metrics.
If the BE's disagree on the estimates, then the entire team should discuss the PBI, and perhaps work towards breaking it down into either smaller PBIs or into detailed tasks so that everyone can understand what is required.
You may also wish to look into Professional Scrum with Kanban as that does not use story points for estimating, and simply has the team ask themselves if each PBI meets their definition of workflow. If it does, it gets added to the sprint. If it doesn't, it gets broken down until it does.
Estimation is always a team effort. Whole team should be there for estimating, but if anyone feels uncomfortable, they may drop the question mark and leave the discussion to others. But a designer may also have valuable input for development tasks, as do testers, BE and FE.
"pair-programming" should have been "cross-training" instead.
I had to create this additional comment as there doesn't appear to be an option to edit comments (technical debt within the forum).
Do you believe the team's Developers ought to share accountability for these and all other estimates they make?
I strongly believe that, the major purpose of estimating is to making the story in the same clearance for whole team. I mean , if there are 9 people on team, all of them should understand what is the task about. Why we ought to do this task.
But, sadly, in some practises on forums, guys sharing their expreriences as - showing the done results of user story points in Sprint Review meeting. They say, "we are demonstrating to stakeholders like we began the sprint wiht 55 SP and we completed 45, and 10 is has not completed. So then they are trying to EXPLAIN stakeholders why the rest of 10 is not completed. I would like to see your point also about this when you answer this question.
Any sense of obligation to explain why points have not been completed should be challenged. The focus ought to be on the commitments that have been made, such as the meeting of a Sprint Goal, and the delivery of Done work.
Story points are nothing but guesses based upon what is known at the time the guess is made. Consider this scenario. I am making spaghetti and meatballs for the team to eat on Thursday. On Monday I ask everyone in the team how many meatballs they will eat so that I can buy enough ingredients. You say that you will eat 4 meatballs. Thursday morning comes around and you forget I'm bringing lunch and you eat a big breakfast. Lunch time comes around and you only eat 2 meatballs. Here is my question. Should I penalize you for only eating 2 meatballs when my original goal was to provide lunch for the team? No, I accomplished my goal. Could there be leftovers? Sure but those can be eaten later by me or someone on the team can take them home to their kids.
Estimates are not exact and should never be expected to be. They help people anticipate what they are planning to do. Story Pointing is an ESTIMATION tool. A team does not have to completely agree on their estimates. They just have to come to an agreement on an estimate that everyone can support. I may thing it is a 3 but if another developer feels it is a 20, we should discuss and come to an agreement on something we can support. One of us may know something that the other didn't and gaining that knowledge will change estimates and help to come together on a single estimate.
In the end no one should be held accountable for their estimate. The team should be rewarded for their delivery on an increment that supports the Sprint Goal.