Dealing With Commitment – Priority Order in Sprints

A recent encounter with a new (to my team) Scrum Master has me scratching my head, and I thought I’d get some thoughts down about it. It relates to the order teams are expected to deliver stories in.

My understanding is, and has in fact always been, that when the scrum team commits to work, they are then free to decide the most sensible order of delivery of those stories. But the suggestion this morning is that the team must submit for Product Owner approval for any variation in the order.

Does a team commit to an order when they make their commitment?

An Example

For example, consider this backlog

  • Story 1 – 3 points
    Story 2 – 2 points
    Story 3 – 1 point (investigation)
    Story 4 – 2 points
    Story 5 – 5 points
    Story 6 – 1 point
    Story 7 – 2 points
    Story 8 – 3 points
  • Team velocity – 13 points

Taking this as read, and pretending it’s ever this simple (a sprint without holidays? Never!) the team’s velocity suggests they can commit to the top 5 stories. They may have some concerns about story 5, as it’s a 5 pointer and therefore the largest piece of work, but let’s assume these are absolute business priorities – maybe the 5 pointer is a customer commitment or enables the entire next sprint – and the team takes in the top 5.

As a member of the team committing to these stories, I would absolutely not plan on working on these stories 1-2-3-4-5. However, the Scrum Master suggests we absolutely should, and that any change in order needs to be submitted to the Product Owner who will have the final say.

My objection is – the team committed to the stories. They didn’t commit to the order.

Managing commitment can feel a little like this… what matters least now? What will I wish I’d done now, later?

The Suggestion

In the above example, given say 3 devs and a QA in the team, it would make sense to me to start work on the 5 pointer no later than halfway through the sprint, to allow the 5 points a fair amount of time for test, bugfixes, delays in code review, etc etc etc.

Based solely on the information above, I might suggest starting the 5 pointer at the outset because it has the biggest risk, leaving the investigation til last because a) it’s small and b) it doesn’t require test.

The business priorities are absolute, so for them the order is as represented in the list above. But in terms of team capacity and ability, the team are the people to own the delivery of their commitment once it’s made. They are the people who know, for example:
– There’s an expert for Story 4 who might not be around for week 2 of the sprint;
– Story 1 will be easier to test if we have Story 2 in place first;
– Story 5 will deliver hooks for stories 2 and 4 which make their delivery easier.

When considering process, don’t just think of value – think of risk. Both the risk a process can mitigate, and the risk change can introduce!

The Risk

The objection to this is that it’s “very risky” to start working on anything other than the top priority first. If, for example, we start on Story 5 and not Story 1, we risk only delivering stories 2-5 and leaving the business’ top priority story unstarted. We didn’t give the business the thing they really wanted!

My response to this is to give the team some trust, and some credit. The fact this is the business priority is information for the team, which they will have available when making decisions about how to deliver their commitment. The fact it will be easier to delive ronce we’ve done Story 2 is another piece of information. The fact we have a 5 pointer in the sprint is another piece of information.

  • The risk of leaving a 5 pointer til last MAY BE greater than the risk of starting it first.
  • The risk of spending longer on Story 1 so it can be started “in order” MAY BE greater than the risk of getting Story 2 done first.


  • The risk of insisting teams check deviations from backlog order within sprints MAY BE greater than the risk of letting them have the latitude to decide this themselves!

Realistically the team feel undermined to have a new rule like this thrust on them, when previously they have always had the trust to decide how best to work themselves. This may impact not only their current sprint, but their overall attitude – and, therefore, all the sprints to come.

The Point

Imagine the backlog above contains 100 items, in business priority order. The team commits to the top 5. They are NOT committing to the top 3. They are committing to the top 3, or the top 1. They are committing to a slate of work and they are the best people to make decisions about de-risking that commitment – about delivering it in the most sensible way. Should the PO be aware of the order they are delivering? Yes, certainly. Should they have the ultimate “say-so” if the team decide to deliver Story 5 first? No, I don’t think that is their decision.

Of course, if a team is regularly missing the top priority stories in their sprint, that needs to be addressed, and yes the PO might be best placed to give context to WHY something is a higher priority than something else as part of that. But should the business dictate how teams work in sprint?

I believe that so long as they are delivering to a high standard of quality and predictability, in-sprint priority calls sit firmly with the team.

Further Reading:

The Importance Of Sprint Commitment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s