Agile Zone is brought to you in partnership with:

EXECUTIVE SUMMARY Craig S. Dickson is a software development professional with over 15 years of experience. He has proven leadership experience in both domestic and multi-national start-up and Fortune 500 corporations in the United States, Australia and Europe. Craig specializes in enterprise Java development and cloud architecture and holds multiple certifications including Sun Certified Architect for JavaEE and Certified Scrummaster. Craig brings specific expertise in enterprise software architecture and design, refining development processes and building development teams around Agile software engineering principles. Educated in Australia, Craig holds a BSc(Hons) in Computer Science. He is based in Huntington Beach, CA, and Brisbane, Australia. SPECIALTIES Enterprise Java - Software Development Best Practices - Software Development Team Leadership - Cloud Computing Craig is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

Scrum Anti-pattern : Prioritizing Stories Within Sprints

01.19.2010
| 11665 views |
  • submit to reddit

The prioritization of Stories is a core practice in the 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 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 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 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 is looking for.

The Pictures Are Not Helping

Many diagrams of the 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 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 process that is being followed and in particular about the finite times at which releases should/can be done. If the team has agreed to make a production release after every 4 Sprints and the Sprint length is 3 weeks, then the 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 .

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 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.

Published at DZone with permission of Craig Dickson, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Karl Scotland replied on Wed, 2010/01/20 - 5:15pm

I disagree. I think that NOT prioritising Stories within a Sprint is the anti-pattern. I posted reasons why on my blog:

http://availagility.co.uk/2010/01/20/scrum-anti-pattern-not-prioritising-stories-within-sprints/

Siddharta Govindaraj replied on Wed, 2010/02/03 - 2:40am

I disagree too. I think a big problem in Scrum is the "commitment" that they have to get everything done by the end of the sprint which leads to taking on too much work and doing extra time to complete it. I blogged about this a little while ago here - http://www.silverstripesoftware.com/blog/archives/172

David Draper replied on Wed, 2010/02/03 - 4:05am

Craig,

I think you make some good points but perhaps over-state your conclusion.

I encourage teams to prioritise within a sprint, this encourages collaboration and increases the focus on getting stories really done.

Commitment to a sprint goal is good but we don't want the sprint plan padding with contingence so commitments will be missed from time to time.

I worry a little about your priorities when the business needs to delay release because of the process. I though agile was about responding to business need!

I've expanded on my own approach here: http://www.agiledesign.co.uk/scrum/prioritising-stories-within-a-sprint/

Thanks for opening up the debate. Dave.

Ilja Preuß replied on Tue, 2010/06/22 - 7:49am

Actually, in canonical Scrum, the team doesn't commit to a set of stories, but to a Sprint Goal that is a more abstract description of what functionality will be added during the Sprint:

"The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality." http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit pg. 12

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.