determine story point

@John Tam, In accordance with the Scrum guide, who is responsible for estimating the work?

team struggle with story points, as PO what should you do?

What other ways your development team think is best to estimate? 

Instruct the Scrum Master to resize the story

Why do you think SM has to resize the story?

Stating that the team is "struggling with story points" is incredibly vague.

What problems are the teams having? Are they having trouble understanding the purpose or intent of story points (or more broadly, estimating work)? Or is it that they are having problems reaching consensus on estimates for particular units of work? Or is the difficulty in planning and determining what the capacity is for the upcoming Sprint and how to determine how much work to bring in? Or is it that what the team can complete in a Sprint is radically different than what they can estimate?

Each of these are very different problems with different possible solutions, although some may be related.

As PO, you should work with the SM to ask the team how they feel the estimations are going? Let the team surface the problems they face.

Could be the estimates are too high/too low. Or stories have too much scope creep because of the quality of the story writing needs to be improved. Maybe they spend way too much time getting every last detail before they estimate? 

Have the SM lead a workshop of relative story pointing. The goal of estimating is to provide the ability to tell the difference between similar pieces of work and when it's time to split a story if the value statement is too broad.

You may even have the workshop tease the idea of not estimating at all. Would that be a goal or lead to a huge problem? Solve for "why". Then retro on the change and make another one. Repeat until you get it right.

I'm going to take a stance that might not be to your liking but I feel like someone needs to do it.

Nothing in what you have said indicates a problem other than one you perceive. Can you explain how they struggle with story points?  Are the having trouble reaching consensus or are they reaching a consensus that you don't agree with? I ask that because all of your suggestions lead me to believe that you do not understand your role as a Product Owner.  For example your statement of "have the SM resize the story" makes me wonder just how much you truly understand about the exercise.  The following statement is from the Scrum Guide section that describes the Product Backlog, emphasis added by me.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

So why would you suggest any of these options? 

Instruct the Scrum Master to resize the story

Continue to support the team's decision on sizing

Suggest the team stop the sizing of the user story and add it to the next Iteration as is

Make the team aware of her expertise and decide the size for them

Do any of those options show that you respect the Development Team's ability to do their job?  Do any of them show that you understand the purpose or exercise of estimating the Product Backlog Items?

team struggle with story points, as PO what should you do?

Based on the the statement I provided from the Scrum Guide, as PO you should help them understand and select trade-offs but it is up to the Development Team to determine the estimates. And remember that estimates are based upon the information the Development Team has available to the at the time they make the estimates. If the Scrum Team feels that the estimates are constantly over or under then it should be discussed. It might be that the Development Team does not have adequate information to make estimates and that is a symptom of incomplete refinement.  

But through all of this I still want to know what evidence there is that the team is struggling with the estimates? Are they having difficulty agreeing on estimates or is that the estimates they provide are not to your liking?

Daniel I'll make a statement people may not like as well - it seems like a question with multiple choice answers that's for an exam prep - i may be wrong though.  

 it seems like a question with multiple choice answers that's for an exam prep

A very poor exam prep if true.

This is indeed from the Scaled Agile Prep Test and the question, which i agree is very vague, is still there..  If anyone has to take a guess, what do you think should be the best option in that case?

My best choice would be "Suggest the team stop the sizing of the user story and add it to the next Iteration as is"  

I prefer this option because the the most likely reason that the team is not able to agree to the story size is because they do not have sufficient information to size the story. And if they do not have the sufficient information, then there is no way they can commit to this in the current iteration. 

I prefer this option because the the most likely reason that the team is not able to agree to the story size is because they do not have sufficient information to size the story. And if they do not have the sufficient information, then there is no way they can commit to this in the current iteration. 

So because they don't know enough about it now, they should just pull it into the next iteration without any further work to refine the issue?

If I had to choose an answer it would be "Continue to support the team's decision on sizing".  As Product Owner you have to trust that your development team is doing the best they can.



But as has been said, this is a really bad question.And having a question on any kind of Scrum prep exam that specifically calls out Story Points is a major red flag since nothing in the Scrum Guide mentions the use of Story Points. In fact the word "story" or the word "points" appear nowhere in the guide.  Where is this Scaled Agile Prep Test?  I would like to see more of it so I can determine how vehemently I want to warn people away from it. 

Talk to your Scrum Master about this situation and explain the problems it causes to you.

Raise your concerns during the Sprint Retrospective meeting and try to improve your collaboration with the Development Team.

I think these are the correct answers in the quiz.

Daniel ,

It is a question in the "PRACTICE TEST: SAFe 4 Product Owner Product Manager Exam (4.6)". 

Below is the exact text of the question.

The team is struggling to agree on the story point sizing of a new user story. The Product Owner was previously a related domain expert and feels the team is wasting time. What should she do?

Continue to support the team's decision on sizing

Make the team aware of her expertise and decide the size for them

Suggest the team stop the sizing of the user story and add it to the next Iteration as is

Instruct the Scrum Master to resize the story

"Continue to support the team's decision on sizing", would have been my choice as well if the question didnt specify that the team was struggling to agree on the size. If they are struggling to agree, then I assumed that they are not able to make a decision.  

I wouldn't assume that they can't make a decision. I've worked with a lot of teams that struggle to come to full agreement on a specific size but they can agree to use a specific size.  The principle of "disagree but support" comes into play with this.  As a Scrum Master I help the understand that this is just an estimate, not a committment.  Especially if there is a number that is between the upper and lower.  Why not "disagree but support" the use of the middle number?  The conversation will serve as a reminder that there are still some unknowns and the actual effort can vary.