How to identify optimum story points for user stories

Question

I would like to discuss a scenario in the sprint planning. Suppose the total velocity of the sprint is 30 as per the previous sprints. The objective of the product owner is to plan 3 stories with 10 story points each in current sprint. During the sprint planning, the development team saying that they want 30 days to complete one story. As a product owner, how should I convince the developers? Identifying the story points is not a one sided opinion. Right ?

Answer 1

I'm afraid you are mistaken. In Scrum, only the dev team doing the work has a say on how much they can take on and, therefore, how many points it is.

You can read the Scrum Guide at https://www.scrumguides.org/index.html

Now, to your last point, the whole effort is fairly collaborative. As a PO, you represent the user need to the team. If they say it is a month to fulfill, then it raises a question: what can be provided in the next sprint? Also, if the pace of development and the budgetary constraints are not aligned, the PO and team may be able to discuss some creative solutions to that problem. In those conversations, the team is helping identify a technically viable solution while the PO is helping ensure it will still meet customer needs.

Answer 2

From your comments:

How the product owners will ensure that the story points are not under estimated or over estimated. The story points will change based on the expertise of the developer. Right ?

No. Story points are an absolute estimation of complexity. So a Senior Chief Head Developer and a Junior Intern Software Assistant should estimate the same task at the same number of points.

Obviously the former might implement it in 2 hours while the later takes 5 days. And that's what the velocity is for. How many points can your team take on in their iteration. But 10 points is a measure of complexity of the work, not time it takes to do it. Otherwise, how would the two people ever come to the same conclusion in their estimate.

So this is a self-correcting system. You cannot really over- or underestimate. Even if all developers always estimate double (or half) of what would be "correct" the system will auto correct, because all you have now is double (or half) the velocity. Whether a story is 10 story points or 47 is meaningless, the only value of this number lies in the estimation of how many stories you can fit in a sprint.

Answer 3

TL;DR

Jacobs' Scrum Tautology℠ says:

Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.

The current approach you're describing is not agile, not Scrum, and abuses the velocity metric as a proxy for setting a coherent Sprint Goal. Don't do that.

Address the Underlying Challenges

Some of the challenges you're facing are likely due to:

1. Work that's too large to fit into a single Sprint. INVEST criteria and story decomposition can help with this.
2. Lack of an over-arching Sprint Goal. A Sprint Goal is required by the Scrum framework, and a central coherence is useful in any collaborative development framework.
3. Velocity is being misused as a measure of productivity. Velocity is a measure of a team's historical capacity, rather than a directly-correlated measure of the team's speed or productivity. It should be used primarily during Sprint Planning to forecast Sprint Backlog capacity for the upcoming Sprint.

Your team should hold a retrospective, perhaps using a root-cause analysis tool like the Five Whys, to identify the real issues that the Product Owner and Development Team are facing. Only by addressing the underlying process problem, and collaborating on a solution together, can the agile implementation truly work.

Review the Roles and Responsibilities of the Framework

The objective of the product owner is to plan 3 stories with 10 story points each in current sprint.

This objective is wrong. In Scrum, the Product Owner works with the rest of the Scrum Team to develop a Sprint Goal, and the Development Team then selects work off the top of the Product Backlog to meet that goal within its available single-Sprint capacity.

Only the Development Team can estimate stories. Only the Development Team can select work for the current Sprint. If the Product Owner is assigning work or setting capacity targets, then there's definitely an issue with the team's implementation of the framework.

The Product Owner provides the vision for the product, and sets the priorities of the items of the Product Backlog. The Product Owner then collaborates with the Development Team to define a potentially-shippable increment of work.

It's not the Product Owner's job to crack the whip harder. It's the PO's job to communicate clearly about what stakeholders and customers need, so that the Development Team can effectively implement a useful increment of product

In other words, the Product Owner defines what's needed, and the Development Team decides the best way to implement it within the current constraints. It is only in the communication and collaboration between what and how that the emergent properties of agile development can be fully harnessed. You can't dress up command-and-control management in agile terminology and expect to achieve the full measure of the framework's value.

Answer 4

Doing the math: assuming 2-week iterations and a 30-point historic velocity, this implies that you have a 60-point story.

Seems to me you have an opportunity to slice the story into smaller chunks.

On another note - strange that all of your user stories are 10-points. If they're all the same, you might consider eliminating estimation altogether.