8

In one scrum team, the PO expects stories to be executed in a defined order in the sprint. This PO usually arranges stories in top-down order and expects stories to be executed in the same order.

I personally felt uncomfortable with this approach, believing the team should be given the freedom to decide the execution order for maximum productivity.

  1. Is it the right thing to do?
  2. Is there any downside of doing this?
1
  • 2
    What is the PO's reason? Is the PO identifying urgent stories that need to be delivered faster than the length of a sprint (if this occurs routinely, it may be a sign that sprints are too long or that some other aspect of the process isn't working)? Is the PO concerned that some stories won't be delivered in the sprint (if so, fix the cause of uncompleted stories)? Is the PO trying to micromanage the team's work (if so, the scrum team isn't self-managing: either actually do scrum or agree as a team on what process you're really using)? You can't address this unless you know why it's happening. May 17 at 4:33

3 Answers 3

19

No, the Product Owner shouldn't be defining the execution of work during a Sprint.

At the Sprint Planning event, the Product Owner and Developers collaborate to craft a Sprint Goal, select Product Backlog Items for development, and the Developers create an initial plan for achieving the Sprint Goal and delivering the work. These three elements are the Sprint Backlog for the Sprint.

The Developers are accountable for the Sprint Backlog. The plan is created "by and for the Developers". Although the Product Owner is involved in crafting the Sprint Goal and influences the selected Product Backlog Items based on ordering the Product Backlog, the Developers select the work, create the plan, and revise the plan at the Daily Scrum (and more frequently, if necessary).

If the Product Owner is exercising control over the Sprint Backlog and the daily work of the Developers, that could indicate micromanaging and perhaps a lack of trust. It also indicates that the team is not self-organizing and self-managing.

2
  • 2
    It could also be a symptom of having long sprints that are more like a marathon, and the PO needing something within a shorter timeframe. Or more likely, there is a false sense of urgency being generated by someone above. May 17 at 3:16
  • 1
    Frequently, stories are arranged according to technical dependencies rather than business priority. Certainly business priority plays a big role, but if story B depends on code written in story A, it doesn't matter how badly the PO wants story B. They need to wait for story A to be developed first. Product backlog tends to be driven by business priorities. Sprint backlogs are a balance of business priorities and technical dependencies. May 18 at 15:45
6

The PO should arrange Product Backlog Items (stories) in priority order.

The highest-priority stories should guide the team to choose a suitable Sprint Goal, and usually those stories will then be included in the Sprint Backlog to support reaching that goal.

Once the stories are included in a sprint, then it's up to the developers to decide how best to meet the Sprint Goal. Often that means executing the highest priority story first, but it could mean (for example) starting the highest-risk story first (to discover as early as possible if the goal can't be achieved), or choosing stories that balance different developers' skill sets.

So it's not wrong to work on stories in a different order to their priorities - the important thing is to achieve the Sprint Goal.

2

The PO's role is to determine what to achieve during the sprint; the development team should decide how to achieve the sprint goal. If the PO truly has useful technical expertise then it makes sense to listen to their input on the most effective ordering of tasks. But unless the PO is also a member of the development team, he/she is probably unlikely to have sufficient insight into the details to make the best decisions.

The fact that the PO wants to set priorities within a sprint strongly suggests that one of the following problems may need attention:

  • Sprints are too long so the PO can't wait to see results. Shorten the sprint.

  • The team isn't delivering everything they forecast to deliver in a sprint so the PO is trying to mitigate that by prioritising the most important things. Reduce the amount the team commits to at sprint planning.

  • The PO lacks confidence in the team. Make sure that sprint reviews are demonstrating results backed up with relevant performance metrics.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.