How to Mess Up Scrum, Part 3

In prior installments, I described a couple of ways to mess up Scrum: Adding work during a sprint and scheduling work for future sprints. This time, I direct your attention to another closely related way to mess up Scrum:

Failure to Prioritize

You know what? Humans aren’t that smart. We can think a lot about a given thing, but we’re not good at thinking about everything at once. Agile development recognizes that by letting us do just one, or perhaps two, things at a time and put aside the things that aren’t immediate. “Do today’s work today!” we say. “Do the simplest thing that could possibly work!” we say.

Those aren’t just cute slogans. They are reminders of how limited we are in our brilliance.

When you mess up Scrum by failing to prioritize the Product Backlog, you’re forcing everyone to think about all the backlog items at once rather than allowing them the blessed luxury of thinking about only the most important items right now. (Aside: strictly speaking, they’re not necessarily the most important things; they are the next things. But as a simplification it works.)

Why it matters

You need to spend some time with the customer or the Product Owner, perhaps during the current sprint, in order to help them order the next sprint or two’s worth of stories or items. Sure, if your Product Owner is exceptionally prepared and integrated with the team, this cooperation is implicit rather than explicit, but it should always happen.

The reason this is important, and why it works, is that people do their best work when they have one thing to do and can focus on it. If you are trying to develop code and someone on the customer side is constantly asking when this thing can get done and when that other thing will be fixed, you’re drawn off task and distracted. Your code will suck and it will take too long to write. And the bit about a “man with two masters” comes into play: implementing the GUI refresh is absolutely enough to deal with at one time. You don’t also want to worry about optimizing the AJAX code behind that.

But more to the point, Scrum is a kind of contract between the Product Owner and the development team. Everyone keeps focusing on the team’s obligation to get stuff done, but you hardly ever hear about the Product Owner’s responsibilities. Simply put, prioritizing (ordering) isn’t for the Product Owner’s benefit. It’s for the team’s benefit. It forces the Product Owner to make a damn decision already and stick with it. Failing to prioritize the backlog is a way of dumping responsibility on the team for working out all the business value in their heads without the business background that is the whole reason for having a Product Owner in the first place.

What you have to do

The first thing, honestly, is to put the Product Owner on the spot. “Ownership” means you get benefits but it comes with responsibilities too. The Owner has to lead the way as much as possible in writing out your User Stories or whatever units of work you use. The Owner has to think through the business benefit of each of these units. The Owner has to figure out the ordering or priority of those units. And (out of scope for this blog entry) the Owner has to close the loop by fulfilling the User Acceptance part of any reasonable Definition of Done.

If you’re a team leader or a team member, the Sprint Planning Meeting is exactly when you’re supposed to speak up and call out the Owner if the ordering is not clear. Application of that ordering should in fact happen nearly automatically: it’s normal to start with User Stories that have point values, plus an expected point velocity for the sprint, so it should be incredibly easy to keep moving items from the Product Backlog to the Sprint Backlog one at a time, accumulating points until you’ve reached that velocity number.

It’s reasonable to rearrange some of the later-ordered items if it makes sense to implement them together. You might have closely related work items on both sides of the line between “this sprint” and “probably next sprint” so bunch them together one way or the other. As always, the main point is to deliver maximum business value for the sprint instead of following a strict protocol.

What if the Product Owner won’t prioritize?

This is another great Agile anti-pattern. Ask yourself, as a team member or leader:

• Are you in fact doing Agile at all?
• Do you actually have a Product Owner, or are you using a well-removed person as an owner proxy? Nothing beats having a Product Owner with the proverbial skin in the game.
• Is the Product Owner committed to the project?

If the Product Owner isn’t committed, or if they steadfastly refuse to set a priority order on tasks, then the sprint is declared broken. You can’t go forward.