Scrum Anti-pattern : Prioritizing Stories Within Sprints

The prioritization of Stories is a core practice in the Scrum agile development process. In fact it is probably the single most important responsibility of the Product Owner – making sure the Product Backlog is prioritized properly to maximize business value (a.k.a ROI). However, there is a common anti-pattern that I see regularly in which the Product Owner and the Delivery Team act complicitly to establish a priority order for Stories that are being committed too within a single Sprint. The need to do this comes from a negative place and it has dramatic consequences for the Delivery Team.

When Things Are Working Well

The Delivery Team meets in the Sprint Planning Meeting at the start of each Sprint and the main output of that meeting is reaching a whole-team commitment to deliver a well defined set of Stories within the coming Sprint. The Stories that are chosen come from the top of the prioritized Product Backlog and are moved into the Sprint Backlog.

The key is that the commitment that the Delivery Team makes is to deliver a set of Stories by the end of the Sprint. The Delivery Team is empowered by the Scrum process to self organize to meet this commitment – in other words, they take the committed too Stories and create a development plan that is the best (however they define “best”) way to deliver those Stories. This self-organization is so fundamental to Scrum that statements similar to “the Delivery Team is empowered to do whatever it takes to meet the commitment” are not uncommon. This means the order of working on the Stories and who works on specific Stories among other items are entirely up to the Delivery Team.

After the Sprint Planning Meeting, the Product Owner knows with confidence that in 2, 3 or 4 weeks from now (depending how long the Sprints are) that he will be taking delivery of a known set of Stories and can begin to inform the necessary stake holders of this fact.

Explicit Story Prioritization

However, if the Product Owner feels the Delivery Team has a poor track record of meeting their commitments, then the Product Owner cannot be confident that the Stories he is expecting at the end of the Sprint will actually be delivered. So the Product Owner now often feels it necessary to give some guidance to the Delivery Team as to which Stories they should concentrate on if they can see they are going to miss their commitment. This guidance usually sounds something like “if you can’t get them all done, I would rather you do Story #37 and we can push #56 to the next Sprint”.

Once Stories are prioritized within a Sprint, the meaningfulness of the Delivery Team’s commitment evaporates. A commitment to deliver a prioritized list is more akin to saying “we will do our best and do as much as we can”, which is certainly not a draw a line in the sand, do whatever it takes, take no prisoners style commitment, which is really what Scrum is looking for.

The Pictures Are Not Helping

Many diagrams of the Scrum process represent both the Product Backlog and the Sprint Backlog as stacks of Stories waiting to be done. Usually the only difference in the representation is that the size of the Stories in the Sprint Backlog are smaller than those in the Product Backlog.

The problem with the similarity in this visualization is that there is actually a very big difference between those two groups of Stories – specifically, one is prioritized (the Product Backlog) and one is not (the Sprint Backlog).

The Sprint Backlog would be better represented as one large single block of work – to emphasize that the commitment is to all of the Stories. An alternative would be to represent the Stories as a jumbled group, emphasizing the lack of prioritization. Yet another alternative would be to draw the Stories like Post-Its on a wall to emphasize that they can be chosen in any order the Delivery Team desires.

Subtler Forms Of Story Prioritization

Sometimes the prioritization of Stories within a Sprint is not as obvious as the last scenario. For example, what if the Product Owner requests that a particular Story be finished by a certain date which is before the end of the Sprint? Perhaps the Product Owner wants to promote a Story to production ASAP to meet a business need, and not wait for the rest of the Stories in the Sprint. The problem with this is that it removes some of the flexibility and power that is given to the Delivery Team to self-organize. The Product Owner has put a stake in the ground, and all the organizing by the Delivery Team is anchored around that stake. This will likely decrease the efficiency at which the Delivery Team is able to work during the Sprint.

The solution to this problem is organizational in nature and as a result it can be difficult to achieve. What the Product Owner needs to do is reach out and educate the necessary stake holders about the Scrum process that is being followed and in particular about the finite times at which releases should/can be done. If the Scrum team has agreed to make a production release after every 4 Sprints and the Sprint length is 3 weeks, then the business needs to start thinking in 12 week cycles. The Product Owner needs to make sure that this is happening so that mid-Sprint production release dates are no longer being requested by the business.

Another subtle way that Stories get prioritized within Sprints is by creating implementation dependencies between Stories. For example, if Story #41 must be done before Story #42, then effectively #41 has now been given a higher priority than #42. Once again this constrains the choices that the Delivery Team has to organize the work to be done during the Sprint to meet it’s commitment, and inevitably reduces the team’s efficiency.

There are a couple of solutions to this problem. The best solution is to write Stories that are independent and can be implemented without reference to other Stories. The alternative solution if writing independent Stories is not achievable, is to schedule Stories that have dependencies between them into different Sprints than each other. From the example above, Story #41 could be done in the current Sprint and Story #42 would be done in a later Sprint.

The Retrospective

There is nothing in the Scrum process that talks about Story priorities within a single Sprint. If the Product Owner or members of the Delivery Team on your project are talking about Story priorities within a single Sprint, you have at least one (maybe several) problems you need to address.