Prioritising stories within a sprint?

In a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their approach (when working with Scrum) to prioritisation of stories by the product owner within a sprint.

Craig has a valid concern that we might loose sight of our Sprint commitment if we have high and low priorities within the sprint, what if we don’t get to low priority stuff, well it was only low priority! He also raises concern over the degree to which the team is empowered if the Product Owner specifies a priority order for within the sprint.

By contrast Karl has his focus firmly on WiP (work in process), and through that lens the sprint is secondary to a focus on flow, prioritisation will encourage the team to focus on flow. I have some sympathy with this point of view.

As is so often the case I feel that I fall between these two camps.

  • I believe in an empowered team who pull from the backlog
  • I believe in the team making a commitment to a sprint scope
  • I believe in the team self-organising around moving that scope through to releasable product

But, there is always a but, these things don’t preclude prioritisation.

We pull from the backlog in order to take into account team capacity / capability. We pull in the correct amount of work with an appropriate profile e.g. not all database heavy wok if we have limited DBA capability. This means that the team may not always pull items from the very top of the backlog. The team commitment is an open honest expectation that this work can and will be achieved by the end of the sprint. We don’t sack or punish the team if a commitment is missed, in fact it could be argued that the commitment should be missed from time to time due to special causes. We don’t want to pad sprint plans with high amounts of contingency. Finally the team self-organise around achieving the goal.

When I introduce teams to Scrum I recommend working against a prioritised sprint backlog. Why? The prioritisation helps in a number of ways:

  • The team is challenged to find ways to move stories to Done faster
  • The team is encouraged to collaborate and help each other out in favour of picking new tasks
  • We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
  • Where a sprint commitment is missed we loose 1 story rather than a bit from each story.

So in short, I agree with much of what Craig has said, it should not be the responsibility of the PO to prioritise the sprint backlog. However, I do see the need for the team and PO to collaborate in order to ensure that the needs of the business do not take second place to the needs of the process. I also share much of Karl’s motivation with respect to limiting WiP and achieving Flow.

For me prioritisation is a strategy that a team can use to self organise around a given sprint commitment. It encourages collaboration and mitigates risk, how can that be bad?

2 Responses to “Prioritising stories within a sprint?”

  1. David Draper

    I see a risk of us violently agreeing :)

    First of all, “Priority:Must” as you put it is not helpful, for me prioritisation is simply this one first. This is a distinct conversation from scope i.e. must vs. won’t.

    As with any guideline there are exceptions – I don’t propose for a moment that we replace common sense with prioritisation.

    The focus of the post was in response to common advice given to Scrum teams. Limiting WiP (in terms of stories) in this context is achieved by the sprint. The question posed was “should we prioritise stories within a sprint?”. My response was yes, this could be combined with task level WiP limits though this is not common.

  2. Ruud Rietveld

    You say you recommend using prioritisation in a sprint. I think I want to achieve the same result, but I would not call it prioritisation.
    You say prioritisation helps because:
    * The team is challenged to find ways to move stories to Done faster
    * The team is encouraged to collaborate and help each other out in favour of picking new tasks
    * We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
    * Where a sprint commitment is missed we loose 1 story rather than a bit from each story.

    I do not see how prioritisation helps in that. You only need to say that you want to limit WiP. “Priority: Must” has never incentised people to work harder.
    Prioritisation can also work against you: If there is time left at the end of the sprint for only the smaller bottom unstarted story, and not time enough for a higher-up unstarted story, you have to start the higher-up one, and will end the sprint with two unfinished stories instead of one.

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>