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.

Did you find this post interesting? Share it with your favorite tool:

Maurice le Rutte says:

December 19, 2009 at 2:23 AM

If you are free to select the order of items you are going to do in a sprint you have the opportunity to do what feels the best to do at that time. Some people are positively stimulated by finishing a small item first, so picking the low-hanging fruit first gets them in the mood. This is only possible if you are confident that you will also be able to do all the hard stuff too. If not you will quickly start to prioritize within a sprint and maybe even start to do a pattern like ‘70% of the contents are must-do items, the others should-do and you must make the 70% at all cost’

uberVU - social comments says:

December 19, 2009 at 3:07 AM

Social comments and analytics for this post…

This post was mentioned on Twitter by djungowski: #Scrum Anti-pattern: Prioritizing Stories within sprints: http://craigsdickson.com/scrum-anti-pattern-prioritizing-stories-within-sprints/…

Niels Malotaux says:

December 21, 2009 at 4:35 AM

Apparently, the business has to wait until the waterfall of the release or the sprint has been finished. Continuing that waterfall with a perception of what the business needs when the business needs have changed doesn’t seem a good idea to me.
That’s why in the Evo process (similar to Scrum, but…), we have deliveries (never more than two weeks, can be less, as appropriate) to find out whether what we think we have to do is correct. We have weekly TaskCycles to organize the work. One week TaskCycles and two-week DeliveryCycles, allow us half-way a Delivery to check whether we will make it on time and if not, what we will do about it. An Interrupt process allows the business to change what we are doing, of course only once we have established that the new thing really is more important than what we thought we had to do. We don’t just do what the business is telling us, because what people say and what they need may be different and we don’t like to make perfect solutions for the wrong problems.
Evo retrospectives are done every weekly TaskCycle, and a week later we check whether what we changed based on the retrospective really was an improvement. Etc, etc, smell elements that make Evo projects routinely succeed on time.

@ Maurice:
First starting with the small and simple things is a typical trap which easily will waste time: If we first do the easy things and then the more complicated things, we often find out that the easy things still are easy, but have to be refactored because of what we learnt during developing the more complicated things. If we first do the more complicated things, we can do the easier things right the first time. Besides, the easy things are not very risky, we know we can do them. So, first doing the more complicated and more risky things will tell us earlier if we’ll get into trouble. The earlier we know a problem, the more time we have to do something about it.

Igor says:

December 21, 2009 at 5:28 AM

Negotiate the priorization of the stories within the sprint is part of the sprint planning 1 meeting. You should follow the sprint backlog priorization, otherwise what’s the point of prioritizing? If you have a business need that needs to be addressed before the end of the sprint, then put this story as the top priority of the sprint backlog, and make it clear to your team that this story is very important and has to be delivered ASAP. It’s ok to do that.

It’s not ok to prioritize between must have and should have – if you, as a P.O., are doing so, you’re doing it wrong – the point is that the team has to pull the work to be done, not be pushed on. This is a typical problem with old school P.M.’s. If something is ’should have’, then it shouldn’t be part of the sprint. If the P.O. is telling the team “I need you to deliver this set of stories” on the sprint planning, then it’s not a push system – it’s just that old habits die hard, and you’re not empowering the team to decide on which Product Backlog items they’ll work on the next sprint.

Another error in not giving a damn about the prioritization of the stories within a sprint is that you will probably get into the mistake of paralleling a multiple stories. The point of scrum is indeed to promote self organization and empowering, but constraints apply. And prioritization is one of the cases that is out of the league of the team to decide on. It is ok that sometimes one or two stories walk in parallel. It’s ok to the team to negotiate the prioritization of a given sprint backlog item during the sprint, because of other constraints. The team has indeed to self organize, but it’s not cowboy do-what-you-want style. If the team finds a problem with a story, it should summon the S.M and P.O. and solve the impediment, not just go on and work on another story (even if that is the case after the P.O. and S.M. are summoned!)

This is based on my experience as a 3-year practitioner of scrum and agile – I’m interested in hearing more about the experience of the author if he’s willing to share, and what made him arrive at those conclusions.

I do not agree that this is an anti-pattern. How many times did you see that happen and cripple the team?

Cheers!

Saurabh Banerjee says:

December 22, 2009 at 11:07 PM

I don’t think there is any harm in prioritizing stories in a Sprint as long as this adds business value. If the business really needs a valuable feature and time to market is important, then the team should do its best to deliver it before the rest of the features in the priority list. When commiting to multiple stories with different priorities in a Sprint, the team should try to implement the higher priority stories first (irrespective of how hard or how easy it is to implement it). A self adjustin team will typically avoid a lot of work in progress which cannot be completed within the Sprint. It is more important for the business to get a single high priority story completed 100% than to have two high priority stories completed 80% each. The team needs to value the business goals first. I don’t think any process on earth will deny that.

In my team everybody pitches in (if required) on a single story to get it 100% complete. My mantra is “Minimize Work In Progress”. Focus on business value delivered.

james peckham says:

January 9, 2010 at 6:41 PM

I always prioritize to do the story that will be the most architecturally significant and touch all the way through the architecture.

Sorry to add more but the premise is to “Fail Fast”

Scrum Anti-Pattern: NOT Prioritising Stories Within Sprints « AvailAgility says:

January 20, 2010 at 1:48 PM

[...] an article on Agile DZone claiming that prioritising Stories with a Sprint is an anti-pattern. He blogged this in December last year, when I noticed it and grumbled on twitter, but no more. Now that its [...]