Can dev team override story priority decision from PO in Sprint planning second phase?

I assume the Dev. Team should share this finding with the PO who makes the final decision.

I wrote that article. I was referring to the Development Team's prioritization of Sprint Backlog items to meet the Sprint Goal.

The Development Team wholly own the Sprint Backlog and so they, and not the Product Owner, determine any prioritization.

The PO owns and prioritizes the Product Backlog. Once Product Backlog Items have been inducted into a Sprint Backlog, the PO can expect the corresponding work to be delivered in the form of a potentially releasable increment that meets the Sprint Goal. How that work is done during the Sprint is up to the Development Team.

Ian, you're right talking about the time after planning, the DT owns the SB. However what you write in the article regarding the 2nd part of the Sprint Planning is confusing me:

The team will prioritize the Sprint Backlog so that the risk of not meeting the Sprint Goal is minimal. This should take into account any external dependencies that must be resolved before the work can be completed.

Does that mean that DT changes the order of the selected PBIs? I don't agree with that. I consider that should have been done before during the PBR session(s). If DT doesn't reach the Goal and doesn't complete all selected PBIs - the PO would be very surprosied to know that , say, top 3 Stories were not completed as the DT changed the order.
Did I understand it correctly?

By the way, in the article I also described some of the compromises that are made in order to run a Scrumban operation (such as being flexible about a Sprint Goal). That's not Scrum, and so I don't recommend using that article for examination purposes. Use the Scrum Guide instead.

> Does that mean that DT changes the order of the selected PBIs? 

That's a very good question. When the PBI's are inducted into the Sprint Backlog, we might presume they are taken in natural order...i.e. as they were originally ordered by the PO in the Product Backlog.

However, there is nothing in the Scrum Guide which says that this order *must* be preserved. Moreover, the Guide says that the Development Team own the Sprint Backlog, and so we can infer that they may in fact prioritize it as they see fit.

In other words - strictly speaking - the PO has the right to expect the Sprint Goal to be met, and for the team to do their best to achieve that goal. However the PO has no right to expect certain PBI's in the Sprint Backlog to be actioned in preference to others. That would be the Dev Team's call.

In practice though, I concur that it is reasonable to action the PBI's in natural order. Let's also remember that there is nothing to stop a Scrum Team from *agreeing* amongst themselves to do exactly that, perhaps so as to deliver an increment in multiple small batches.

NB, let's also bear in mind that PBI's have a value as well as an order. So if the PO values a certain item more or less highly than others, there is an attribute for capturing that information, and which is quite independent of the item's position.

So to make sure I understand clearly, Ian, Is it okay for DT to change the priority of the PBI"S as long as they meet the goal. So 3rd or 4th PBI in order might be heavy on dev and so on testing. In this case Can dev team not pick that up early in the sprint and in parallel work on others in order.
Just with personal exp, in last sprint we just could not make a PBI that was lowest priority in sprint because of huge work associated with it.
Could we have changed the order among ourselves keeping PO aware and could have achieved sprint goal in time with all stories?
Appreciate your feedback

> Is it okay for DT to change the priority of the PBI"S as long as they meet the goal

Yes. In fact it is important for a Development Team to constantly update the Sprint Backlog so that the Sprint Goal can be met.

> Could we have changed the order among ourselves keeping PO aware

That would be a good team behavior, yes. Bear in mind that the PO and the team should collaborate throughout the Sprint to make sure that the Sprint Goal is achieved. The PO can, and should, clarify the scope of the Product as it relates to the current Goal when necessary.

I have the same question though. Imagine the team doesn't complete the stories in time. And say you've put the top story to the bottom and this is the one that hasn't been finished. How would you explain to Product Owner that the top ordered PBI was not finished? Do you think she'd be happy with that?

I dont think, This drastic change of moving top priority to last by DT can happen or should happen in close to ideal world. It still remains top priority and DT needs to make sure that they start working on that since beginning. I was talking of the priority 3/4 to moving it early. Some less priority may be lengthy.

I may be wrong but PO and wont agree to such drastic change even if DT proposed, I believe.

> I have the same question though. Imagine the team doesn't complete
> the stories in time. And say you've put the top story to the bottom
> and this is the one that hasn't been finished. How would you explain
> to Product Owner that the top ordered PBI was not finished? Do you
> think she'd be happy with that?

The only reason for the Development Team to change the Sprint Backlog is to make the Sprint Goal more achievable. The Sprint Backlog, including the PBI's that were negotiated into it, is a plan and not a specification. So as long as the Goal is met then yes, I'd expect the Product Owner to be happy with any decision the team makes regarding the Sprint Backlog it ultimately owns.

Let's illustrate this using an extreme example. Suppose a Scrum Team agrees its Sprint Goal during Planning, but the PO disappears until the following Review. That wouldn't be a great implementation of Scrum but it wouldn't actually break the rules either. So at the end of the Sprint, the Development Team could say to the PO "Guess what? We threw away all of the PBI's that were in the Sprint Backlog, because when we got down to it we found they didn't really help in achieving the Sprint Goal. We replanned the Sprint totally...but we got the job done and the goal we agreed has now been met. Here's your potentially releasable increment!"

In Sprint Planning, once a Sprint Goal is agreed all of the selected Product Backlog Items (PBI's) become subservient to the achievement of that Goal. Once that Goal is agreed, the PO should care about getting the functionality it represents. The Product Backlog should express the totality of undone work, and it should be revised by the PO each time he or she is in receipt of an increment. The Product Backlog is not a checklist of things to be marked off in each Sprint. If this is not the case, and the PO values certain PBI's in a Sprint Backlog more than the Goal, then Scrum has not been properly implemented.