Pac-Man and Priority: A Backlog Story
A bit ago, I got into a disagreement with the VP of Application Development about a post on the company intranet. The post was aimed at Agile Coaches, and Scrum Masters, and how we should be assessing the company’s Agile maturity. The bit of the post that I disagreed with was: “The team backlog is prioritized.”
There’s different schools of thought when it comes to backlog refinement (some folks still call it grooming). But here’s the thing. I don’t agree that it’s about priority. So I commented my take on it. Here’s the VP’s reply that set me off:
“Priority is a complex value to calculate, but it absolutely determines the order in which things should be done.”
When I first started out as a Scrum Master I agreed, but now that I have skin in the game, my opinion has evolved. That being said, having 14+ years under my belt in app dev as a Front End Developer in a former life, when it comes to corporate politics, like Kenny Rogers, I “know when to hold ’em, know when to fold ‘em.” So I let it go, refraining from dropping further replies on the post.
I’m not arguing the complexity behind calculating priority; I just don’t care. Nor do I think it has value in what a product backlog looks like. Not even the Scrum Guide gives credence to prioritization. It mentions the word “priority” only twice — in the Product Owner, and Sprint Backlog sections — and in different contexts.
“The Product Backlog is an ordered list of everything that is known to be needed in the product.” — The Scrum Guide
Because so many folks were getting ridiculous about priority, the powers-that-be changed the language of the Scrum Guide back in 2010, and removed the word. The intent of backlog is to determine the order in which things should be worked. Priority is about what’s the most important thing in the universe to stakeholders at that time. It may be important, but there’s a set of logical steps that must be taken in order to get that shiny, new object out the door.
If you’ve read my other posts on Scrum + Hip Hop, you know I’m all about analogies. And that’s where Pac-Man comes in. If you’ve never played, the object of the game is to clear the board. So let’s consider clearing the board the priority of Pac-Man (unless your priority was to get the highest score, but that’s a whole other post).
To achieve this goal (or meet the priority), you’ll need to eat the Energizers (the big-ass glowing dots), and super charge Pac-Man like Mario. You gotta do this because of the barbershop quartet of ghosts stalking you (the impediments).
For reasons I still don’t understand, when you eat an Energizer (called Power Pills in the cartoon), it scares the hell outta the ghosts. They freak out, turn blue, and throw deuces. At that point, you can chase them down, gobble them up, and send them back to the “monster bull pen.”
At any point in software development, there can be a sudden shift in priority. In Pac-Man, shifting priority comes in the form of random fruit bouncing around the board from outta nowhere. The first one the scene is a bunch of cherries. If you scarf them down, you get 100 points. Cool? Later on in the game, more random fruit appears. Each one is progressively worth more points. I’m not sure why, but a Galaxian Boss (2000 points), a bell (3000 points), and a key (5000 points) come around too. I’ve no idea why Pac-Man craves eating stuff like that. Anyway, when the fruit appears, priority shifts from clearing the board, to sating the yellow dude’s bizarre cravings.
Even though something has a designated priority, or level of importance, it shouldn’t dictate that it’s the first thing to be worked; especially if there’s prerequisite steps to take. Whether the priority is to get to that delicious fruit, or ghost-scaring Energizers, you still gotta choke down all those damned little yellow dots first.
In terms of video games with a weird yellow dude obsessed with eating things in his path (his wife shared the same obsession), clearing the board may be the priority, but isn’t the first, nor only step. If it were, Pac-Man would be one crappy, boring video game, and no one would’ve found value in playing it.
When it comes to a dev team’s backlog, the same is true. The highest priority may be to build an API so internal teams, and external vendors have a single entry point to connect to superFancy_thingaMaJig, but the prerequisite steps along the way are those tiny yellow dots. So many dots. They aren’t the most important things in the universe to stakeholders — and most likely will never be — but they’ve gotta be done before anything else.
So let’s focus on what needs to be done, in the order in which teams need to execute. Ordering your backlog to mimic this pattern, instead of leaning on a complex calculation of what priority is supposed to mean, should make backlog management less of a chore.
That’s my two cents. What’s your take on priority?
