Priority of Sprint Backlog Items

Hi Aishwarya,
there is an interpretation of the Scrum Guide which suggests that the Product Backlog Items which are pulled into the Sprint Backlog are nevertheless still part of the Product Backlog until they are done. This means they are still ordered. So there is no need to prioritize them, because the priority was already one of the criteria for sorting.

> ...Product Backlog Items which are pulled into the Sprint Backlog
> are nevertheless still part of the Product Backlog until they are done.

That's correct. Items cannot be removed from the Product Backlog until they are Done or the PO retires them.

> This means they are still ordered. So there is no need to prioritize them

PBI's can be inducted into the Sprint Backlog in natural order, i.e. the order in which they appear in the Product Backlog. However, the Development Team have the right to order them, along with the supporting tasks, in any way they see fit. The Development Team's duty is to provide an increment of functionality by the end of the Sprint, and if the re-ordering of the Sprint Backlog helps them to do so and to meet the Sprint Goal, then that is their prerogative.

The Product Owner is not normally a stakeholder in Sprint Backlog ordering because he or she only has the right to expect an end-of-sprint increment. How that increment is delivered is up to the Development Team.

Remember that the PO has the last saying about the order of Product Backlog. This includes, if we follow the interpretation above, the part of Product Backlog which belongs to the Sprint Backlog. So the Dev Team does not have the right to reorder it in any way they see fit, but they have to consult the PO.
But the question is: Why should they want to reorder it without the PO? If the order is relevant, then they have to talk to the PO anyway, because it is about the probability for getting things done. If it is not relevant, because they follow the Sprint Goal anyway, they don't have to reorder it at all.

> If it is not relevant, because they follow the Sprint Goal anyway, they don't have to reorder it at all.

That's correct. The Development Team have a duty to meet the Sprint Goal. They are not required, in Scrum, to deliver the items in the Sprint Backlog in any particular order. Nor can the PO expect the items to be delivered in any particular order. The PO can only expect an increment to be delivered at the end of the Sprint which meets the agreed Sprint Goal.

Therefore the Development Team do not *have* to order the Sprint Backlog differently from the order in which the items were negotiated from the Product Backlog. However the Development Team certainly have the right to do so without consulting the PO. The Development Team wholly own the Sprint Backlog, which is their plan for delivering the agreed Increment.

Changing this order of work does not affect the order of corresponding items in the Product Backlog, which the PO wholly owns.

Thanks Ian and Ludwig.

I believe Sprint Backlog need not be prioritized explicitly,for as you both said - Items are pulled from Product Backlog into Sprint Backlog, and hence they are already ordered in the way Product Backlog Items are. If however, the development team feels the need to re-prioritize the Sprint Backlog items for some reason, they can do it in any way they want as the Sprint Backlog is owned by them.

I read somewhere that Sprint Backlog is "ordered" by the "Product Owner", which led to the confusion. Thanks to you both for the explanation.

Changing this order of work does not affect the order of corresponding items in the Product Backlog, which the PO wholly owns.

Ian, are you saying you create duplicates of Product Backlog items each Sprint Planning? So you have to keep track which Sprint Backlog Item belongs to which Product Backlog Item?

No, it's simply the case that the priority of a PBI relates to its order in the Product Backlog, and not to any order it might be given in the Sprint Backlog.

The Development Team can plan to action their tasks or work items in any way they like. The PO can expect to receive an increment by the end of the Sprint, but has no right to expect the selected PBI's to be actioned during the Sprint in any particular sequence.

I am a PO and this is all nice and beautiful to read. But in reality, if you are constantly facing a partial increment at the end of the sprint, i.e. sprint goal is not being met, then the PO has an interest in knowing what parts of the sprint goal are being delivered, i.e. he or she has an interest that the PBIs from the product backlog are being worked on in the given order.

Thanks,

Ralph

I am a PO and this is all nice and beautiful to read. But in reality, if you are constantly facing a partial increment at the end of the sprint, i.e. sprint goal is not being met, then the PO has an interest in knowing what parts of the sprint goal are being delivered, i.e. he or she has an interest that the PBIs from the product backlog are being worked on in the given order.

That's an altogether different scenario, though. And one that is covered in the Scrum Guide: 

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

So if the scope of the sprint needs to be renegotiated because the increment will not include all the forecasted PBIs, then yes, the PO needs to be involved and has a say in what PBIs are dropped from the Sprint.

That being said, if you are constantly facing a partial increment you should address this issue in the Sprint Retrospective and you should also make sure your Scrum Master will get to the bottom of this and address the underlying impediments. Why does the increment constantly include less than forecasted? Is the team overcommitting? If so, why? Is there external pressure making them feel they need to overcommit? Are the estimates off? Are the PBIs unclear? These are just some of the impediments that may cause the situation you describe. Your team needs to get to the bottom of that and your Scrum Master must help your team to fix this.

Simply having the PO meddle in Sprint Backlog ordering will only treat the symptom. And it will rob your team of its self-organisation. Don't treat the symptom. Find the root cause and address that.

I am a PO and this is all nice and beautiful to read. But in reality, if you are constantly facing a partial increment at the end of the sprint, i.e. sprint goal is not being met, then the PO has an interest in knowing what parts of the sprint goal are being delivered, i.e. he or she has an interest that the PBIs from the product backlog are being worked on in the given order.

If I may

When a team commits to a sprint goal, then in order to meet that committment, should they not have the option to self- manage the way in which they achieve the goal or they are no longer responsible for the delivery of the value?

If a PO controls what order the work is done becuase of the mistrust or risk mitigation then the PO can control the way in which the work is being done in the Sprint, to an extent can this pressure affect the work that is being agreed to be pulled into the sprint.

Seperately, If the Team is continually failing to meet their sprint goals, the question needs to be asked, are the team taking more than they can handle and why. You have an uphappy team, an unhappy PO and unhappy stakeholders hmm.

I suspect a more detailed investigation into the Team's cohesion and well-being is sought, possibly some Team coaching or where possible fresh retrospectives by swapping facilitators

+1 to Julian's thoughts above.

IMO, the Scrum Guide is vague on whether PBI's in the Sprint are still on the PBL or not.  Ludwig took the position that they are, and I take the position(interpretation) that they are not.  However, regardless of your implementation, any attempt by anyone other than a Dev Team member at strongly influencing the order or plan of attack for the Sprint Backlog is a violation of Scrum.  The Dev Team may do as they wish so long as they honor the Sprint Goal first and foremost.

I base my view that they are not on the PBL any more by looking at the language in the SG regarding cancelling a Sprint:  "All incomplete Product Backlog Items are re-estimated and ***put back on the Product Backlog ***"

Having said that, there are statements in the SG that would also indicate to the contrary, so that is why I said it is vague.  Regardless though, the Dev Team self organizes.  So, there is no "priority" or "order" of PBI's that are in the current Sprint.

Also +1 to David.

My view that items remain on the Product Backlog until they are either Done or retired. However, I also talk merrily about items being “returned” to the Product Backlog in the event of Sprint Cancellation...or indeed returning items which remain undone at the end of the Sprint. It isn’t that I actually see items moving from one backlog to another. It’s just the vagaries of language, and I struggle to find better words which economically and properly describe the situation.

Good points Ian, and the ALM tools of course have an influence here too.  

Hi.

Firstly the Goal of a Sprint is to finish all items picked from the Product Backlog in the Sprint, but it is not a requirement. That points in the direction of equal (or no) priority for all items in the Sprint, once they are within the Sprint Backlog.

Secondly, the sprint includes at least one high priority process improvement from the Sprint Retrospective. How does that relate to the items from the Product Backlog? The way I read The Scrum Guide, it does not. It doesn’t origin from the Product Backlog and hence the PO hasn’t applied a priority to it in the same way as for the Product Backlog items. Again, this points to equal (or no) priority for everything in the Sprint backlog.

Thirdly: The Development team is only one that can change the Sprint Backlog during a Sprint. Which means that the PO has no say in that decision, formally and according to the Scrum Guide. Hence, whatever priority the PO has for the items may serve as a guideline, but the final call is within the development team.

I know that the use of software for all Backlog Items will usually show all items (with their prio), including the ones in the Sprint Backlog, but still...

The Sprint Goal is the goal and that is deduced from the sum of all picked items from the Product Backlog, as well as the chosen improvement from the Retrospective.

The way I read it.....

Sprint backlog is a subset of the Product backlog - having said that, items from PB are picked as per their priority and order already marked by PO - but SB is owned by Dev Team, and I believe they should have authority enough to pick any item in any order based on dependencies (internal/external), pre-requisites, etc. PO and the entire team will obviously be aware of what items are In Progress, but if PO starts managing which item in SB should be picked up first - it is equivalent to having a Project Manager exercising Command and Control.

To summarize (because paragraphs can be mundane):

PB --> owned by PO, Dev team may consult and modify items in PB but PO is accountable

SB --> owned and managed by Dev Team, PO may advise but Dev Team has the final word.

PO and the entire team will obviously be aware of what items are In Progress, but if PO starts managing which item in SB should be picked up first - it is equivalent to having a Project Manager exercising Command and Control

Agree, but I would argue that the prioritization of items offered by the PO is valuable information to the team in determining the completion order of items (along with technical aspects and dependencies).

And I should point out that, as Scrum Masters, we should be fostering a collaborative partnership between the PO and the Dev Team.   We should not promote the idea that the PO throws items over the wall to the Dev Team, and is not involved from that point forward until the end of the sprint.

The 4th Agile principle:

"Business people and developers must work together daily throughout the project."

The Dev Team may own the sprint backlog, but they should be collaborating daily with the PO and other stakeholders, either through information radiation or other communication methods.

Of course, if it is done in collaboration - brilliant.

But in real life, PO eventually ends up dominating the Sprint Backlog - which is not a good practice. So yes, I agree with what you are saying as long as the entire scrum team is functional and happily healthy.

I think the case is more complex. While I understand (and appreciate) the arguments backing the opinion the sprint backlog shouldn't be prioritized and that PO should have no say on the order in which the DT is starting (and completing) work, I have the opposite view. Why?

Well, the PO is pushing for what's best for the product (and business) at any point in time and we trust their analysis and judgment. When ordering the product backlog, they basically make a decision on what brings most value to the business at a certain point in time.

If there's a planning meeting two days from now, and they rearrange the top tomorrow (and drop the top 3 issues to the middle of the backlog, replacing it by other 4), then those new items are the ones benefitting the product/business the most. As such, we can therefore infer the items are a must for the organization. And, if during planning, the 4 newly-introduced top items are selected, among others, for inclusion in the sprint backlog (made of 25 items), then it's safe to assume the business (upon confirmation from DT they can be tackled in sprint) expects those completed and (potentially) released to production asap. Therefore, there is a reasonable expectation that the most important items (nb: 4 items I was referring to) for the business are started first (and the DT should have full authority on the how) and completed first. Because, after all, they sit at the top of the product backlog - now the sprint backlog.

With different release cycles and potential multiple releases per sprint, my arguments have even stronger background. Would you not want, if you release several times a sprint, the top stories released to production as soon as they are Done?

Why leave the DT the option to ignore the order the PO had previously decided, by starting what they want - when they want? As long as there is proper communication/cooperation in the scrum team, DT should understand they need to bring most value first. Remember there is a principle (Pareto's Law) acording to which 80% of the benefits comes from 20% of the features - so we, as a smart scrum team, should always start with what's most valuable/important to the business.

Furthermore (and another argument), in order to control and mitigate risks (market changes, regulator/audit requests, time off/vacation, sickness, staff attrition, etc), we are better off completing top items first.

To conclude, for me the arguments in favour of DT respecting the order of the product backlog - automatically shown on sprint backlog, and starting/completing items as such, have more value than the opposing ones.

Eugene M ->

What about the improvement chosen from Retrospective? It does not have a priority from PO at all, but is also supposed to be carried out in the Sprint. In other words, since it does not have a prio from PO, it is equally important as everything else in the Sprint. And since that is the case, it follows logically that if one item is equally important as everything else, all items are equally prioritized.

That is how I read it. See my earlier comment above if you want to see my other two "findings" in this.. I don't claim to be correct, but in my head it sounds quite logic.

IMO, that would be something different, Kjell, because, while the improvement(s) coming out of the retrospective have a critical impact on the whole team, they aren't in themselves, say, new features. Therefore, depending on their specifics, the team can assess and determine whether it's something that's done straight at the beginning (before anything else - say, new branch process), throughout the sprint (ie, pair programming trials), in the first few days... or later on (such as, if you want, apply a code freeze and ensure prerelease automated testing starts earlier).

PS: To clarify on the code freeze - yes, I'm aware this isn't too agile (in fact many veto it), but it's still practiced and, under certain limitations, offers benefits.

Shouldn't how the sprint backlog is ordered be negotiated between the PO and Development Team?

It is the PO that optimizes the value that the DT delivers. The DT may recognise some backlog items need to be completed before others. The DT can inform the PO and then make the decision on the order of the sprint backlog.

If the DT learn more about the items and how they should be ordered to maximise the value delivered(becasue not every item is always delivered in each sprint) then they should do that.

I believe colaboration is the key here, but the PO should accept that the DT knows which should come first, the chicken or the egg.

While it's true that the DT owns the sprint backlog (The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team), the business priorities (= ordered backlog) are owned by the PO. 

I'd argue the negotiation you refer to should have already happened way before the development work is started, and, at the latest, during sprint planning. This isn't to say the product backlog can't be (re)ordered during sprint planning. I've found other approaches to constitute waste, especially since it may impact (or, worse, nullify) the sprint goal.

Like most of us, I, too, believe collaboration is key, but collaboration happens on a regular basis, not just during the sprint, but also throughout previous sprints (where refinement should've happened).

The above view represents, of course, the rule, for there are exceptions where the DT discovers, very late in the process (during planning, or even after the sprint has started), the initial approach (and the ordered backlog) isn't going to work, hence the need to adapt.