Agile: Work on PBI Stories By Backlog Priority

Question

We are working on an Agile Scrum team. They mention it is good practice to work on PBI tasks first by Sprint Backlog Priority in code development.

Sometimes,

1. When some of the first Priority stories are hard, and I need time to think/have break, (mentally, I like to switch between hard and easy story tasks when I am stuck), makes it easier for head, I can come back and work on story with fresh mind
2. or I see quick 1 hour PBIs in my sprint, that I can push to QA team , (QA is often less busy during beginning of sprint writing test cases, they have more stress during middle or end). It spreads out the work, instead of everyone swarming on tasks,
3. or first priority PBIs are requiring running a long process for integration testing ( I cannot wait all day, and code between while its running in server background)

What are the rules on working on Sprint Story PBIs in order? Is it a hard rule, or can be adjusted? Obviously Priority PBI item have most significance, however can things be accommodated during the schedule?

Answer 1

Unlike the Product Backlog, which is an "ordered list of what is needed to improve the product", the Scrum Guide does not specify if the Sprint Backlog is ordered or, if it is, how it is ordered. Instead, it describes the Sprint Backlog as a "plan by and for the Developers" and a "highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal".

Since the Sprint Backlog is created and maintained by and for the Developers, then the Developers can choose if and how to order it.

When choosing work, the Developers have a lot of things to consider. Perhaps it's better to get some quick work done early in the Sprint. Another approach is to take on the riskiest work first to allow and potential problems to emerge early. Yet another approach is to take on the most important work. Regardless of the order, the Developers should consider the Sprint Goal when choosing what to work on. The team's highest priority for the Sprint is to accomplish the Sprint Goal.

Answer 2

What are the rules on working on Sprint Story PBIs in order

There are none.

All the things you mention are sensible reasons why you might not go in strict priority order.

However, you may want to discuss some of these reasons in your retrospectives. Is it possible that by changing the approach the team takes you might be able to make these exceptions less frequent?

Answer 3

They mention it is good practice to work on PBI tasks first by Sprint Backlog Priority in code development.

There is no sprint backlog priority. So no, this is not best practice.

However, there is a sprint goal. This is the focus of the sprint. And as such, you should probably be working on a PBI that is necessary to reach that goal. If you don't, you are not focusing on the correct thing.

However, the order in which PBIs are worked on is up for the development team to decide, so you can bring that up in the retrospective for a more abstract directive or quickly discuss it in the daily stand-up when you pull a new task for the day, in that specific situation.

Answer 4

The team should only add into a sprint the things that they believe can be completed by the end of the sprint. These are generally high priority items on the product backlog. Since the expectation is that everything will be finished by the end of the sprint there should be no need to prioritise within a sprint except perhaps if there are risks or dependencies that make it prudent to do things sooner rather than later. The team themselves can decide if something needs to be prioritised above anything else.

When teams adopt a pull-system there may be a convention about which items should get picked up next. Such conventions are often informal and subjective because some team members may feel better able to work on some items than others.

Answer 5

They mention it is good practice to work on PBI tasks first by Sprint Backlog Priority in code development.

Sprint backlog is subset of product backlog picked up by the team, during sprint planning session based on priorities set forth by the product owner - whose job is to ensure the team works on those PBIs which are considered to add most value.

When some of the first Priority stories are hard, and I need time to think/have break, (mentally, I like to switch between hard and easy story tasks when I am stuck), makes it easier for head, I can come back and work on story with fresh mind

Here you seems to be planning to do multi-tasking and in general, multitasking specially done across more than 2 task is scientifically proven to be less efficient. If you can really manager multiple tasks and with "fresh" mind - good luck and go forth and try! I don't think Scrum has any strict recommendations here

What are the rules on working on Sprint Story PBIs in order?

As already mentioned by other folks already, Scrum itself does not impose any rules of its own. Sprint backlog is "owned" by the team - it is their commitment and hence you and other folks in a team can decide the order in which those PBIs are sequenced and developed - which best suits your working style, as a team. Since the self-organized team has made the "commitment" for delivering the sprint backlog, the rest of the folks in the team (SM and PO & other key stakeholders) will be "trusting" that the stuff will be done

Obviously Priority PBI item have most significance, however can things be accommodated during the schedule?

"Schedule" is your sprint duration (which is typically 1-4 weeks) and during sprint planning the PO and development team has "agreed" on what the priority PBIs are for this sprint. So as long as the "committed" work is being delivered by the team, the sprint goal is achieved.

Answer 6

What do you mean by "hard user stories"? Bigger or more complex than usual?

We have here two Backlogs: the first is PBIs, while the second is Sprint Backlog Items. Initially PBIs should arranged and ordered according to business priority. I think here, you have to commit to the end-user priorities as described in PBIs where each PBI should be user feature; this feature may be user story or epic.

Before you shift some items from PBIs into Sprint Backlog Items, you have to analyse and understand each PBI. Here you can do accurate estimation of how hard this item is and how much time it needs to be DONE.

It may be a hard task to map each user feature to an item in PBIs, but as you understand these features you will be able to determine the items that need to shifted from PBIs into Sprint Backlog Items and this also depends on the sprint length.

There is no rule on how you start to implement the Sprint Backlog Items. Anyway you must finish your sprint with DONE items. You and your team select the order according to more things like implementation logic.

Look at the sprint as a single milestone, and break it down into related tasks with your team. End-user doesn't care about the amount of story hardness, nor with your efforts, you can think of things by other way.

Try to not measure the item by hard or easy. You have to look at the sprint as a whole, because the sprint contains items which may be easy or hard but they must still fit inside one sprint, and this depends on accurate planning and estimation.

Answer 7

I'm a little perplexed by this situation.

In my organization, a story does not get into the Sprint Backlog until it's already written and all the acceptance criteria are verified and signed off on. So I am always working on the PBI items, getting them ready for the next Sprint. I am usually at least a Sprint ahead; that way we never have this problem.

Hope that helps!