Sprint Planning - Product Owner

It is true that the PO participates in Sprint Planning Part 1 to offer stories to the Development Team.

The PO is not invited to Sprint Planning Part 2, since this is a team-based meeting intended for them to measure their capacity and capabilities against the proposed offer, and to identify the Sprint Goal from the accepted items.

While the PO does not attend Sprint Planning Part 2, they need to be reachable in the event the team has any questions about offered stories or further needs of clarification.

I understand the same for Sprint Planning Part 2 and the Product Owner.

But, about the Sprint Goal, acording to the guide, It is done in Sprint Planning Part 1. And the Scrum Team crat it.
In my opinion, the main actor here is the Product Owner, although the Develpment Team and Scrum Master can help.

Do you agree?

> In my opinion, the main actor here is the Product Owner,
> although the Develpment Team and Scrum Master can help.

Can you clarify what you mean by the Product Owner being the "main actor" in framing a goal which the Development Team are expected to achieve?

Well, The Product Owner is responsible for maximizing the value of the product. And he should have as
knowledge as possible about the product.

In my opinion, this knowledge goes to the Product Backlog (with several items) and its right sorting.

The Product Owner, is the actor with higher probabilities to give better Sprint Goals.

Obviously, the Product Owner must always share and clarify information (about the product) to the Develpment Team And the Development Team and the Scrum Master can also help with the Sprint Goal.


from the Scrum Guide:

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.

I think I meant: main actor=higher probabilities

Do you think some other thing?

Thank you in advance.

David,

I do agree that there can be more clarity in the Scrum Guide around this topic. Per the Scrum Guide:

Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

In my opinion, the Scrum Guide implies that the Sprint Goal is identified at two different times: through collaboration on the Product Owner's offer (Sprint Planning Part 1), and after the Development Team forecasts the work they can complete in the upcoming sprint (Sprint Planning Part 2).

I welcome others to comment on this, but in my mind, the Sprint Goal helps the Development Team to organize around and identify with the value component of their sprint work. I do see the Product Owner providing guidance in this through a stated sprint objective and associated sprint offer, but I am unsure where the PO contribution to the Sprint Goal occurs.

Perhaps my understanding of Sprint Planning is the issue, as there is no differentiation in the Scrum Guide for it (i.e. - Part 1, Part 2). However, my training and experience has always been around the separation of Sprint Planning into two separate consecutive meetings with clear identifiable inputs, outputs, and goals.

Think of the Development Team forecasting PBI's *in order* to craft a Sprint Goal. The goal is thus decided after the forecast, while the forecast itself must be viable for the purpose of goal identification.

This must be a highly collaborative activity. Lop-sided involvement, where one role has more of a stake in crafting the goal than another, will degrade its utility.

In my case I also had two different parts in the Sprint Planning. The Sprint Goal always was done at the end of the first part, with the Product Owner. And in the second part, Sprint Backlog Items were descomposed by the Develpment Team, with the Product Owner out of this meeting. So, the Sprint Goal wasn't touchable/updated in this second part.

Obviously, if an error had been detected and we had needed to change the Sprint Goal then we had called the Product Owner to speak about it.

I do agree that Scrum Team working together in the Sprint Goal is better than only the Product Owner.

Don't you think that the Product Owner can help the Development Team during to clarify the selected PBI and create the Sprint backlog?

He should be available to answer Development Team Questions and sometimes make trade-off.
During this second phase, PBI are breaking down into tasks plus a plan to deliver all the work implemented.
New tasks may emerge during the Sprint, that's why the Scrum Team needs some transparency to make the best possible choices compatible with the Sprint Goal.

in other words, the Product Owner may not be physically with the Development Team but has to be reachable / available to answer questions.
Don't forget that the Development Team should be able to explain how she will turn PBI into a done increment.

It's not mandatory to be there but rather be available / reachable so that the Development Team could have the best possible forecast.
In the previous scrum guide version, this forecast was called a "Commitment" --> a very strong word that give you a good idea of the accuracy of the work to do.

I would like to understand the rational behind lack /less involvement of Product Owner in the 2nd Part of the Sprint Planning meeting?

- Is the objective/purpose to keep PO less involved to enhance the flexibility and creativity of the Development team?
- will the presence of PO in "How" is likely to influence/impact/affect development team's ability to better identify tasks/plan of implementation?

Scrum Guide also stipulates that at the end of the scrum planning meeting - development team should be in a position to explain to Product Owner and Scrum master how the team plans to convert the selected PBI's into "Done","Usable" and "Potentially-Ship able" increment.

Product Owner and scrum master both will need to be available towards the last part of the "How" discussion anyway?

Pankaj Ahuja

I believe in earlier days of Scrum their would be this division in planning but I am finding the PO, SM and Developers and who ever else they may need are needed throughout planning to work to address the two topics proposed in the Scrum Guide.

Topic One: What can be done this Sprint?
Topic Two: how will the chosen work get done?

The Scrum Guide does not detail this because the best solution is what works best in your team and organization. It is not super prescriptive by design to allow for varied solutions. You can't always compare what worked best in one scenario will work best in another.