The Backstory

The other day, I was having a conversation with several people about culling a 200+ item backlog for a legacy application that is being sunset (and the successor of which is already live in some capacity). A business person was arguing that we needed to take the entire backlog into a meeting to vet all 200 stories individually to determine which still need to be implemented. There was a shorter, 70 item list that the business met around each week to prioritize. They hadn’t looked at the other 130 stories in months.

The application did have about a dozen stakeholders who’s business units could be affected either positively or negatively by the prioritization decisions that came out of the meeting. At the same time, to sift through more than 200 stories and decide which stay and which don’t, we were looking at four hours of meetings with several very expensive attendees. I argued that we should take the shorter list into the meeting.

I was in a position only to advise on this one, and I didn’t get my way. What ensued was four hours of - you guessed it - tedium. The majority of those stories had little or no intrinsic meaning to the deciders in the room. We spent a surprising amount of time guessing why something was on the list, how many years it had been there, who really wanted it, and why. Tellingly, the end result was a roughly prioritized list of about 70 stories.

My Take

Prioritization should not be a mind-numbing meeting (or, worse, series of meetings). It should be speedy, efficient and sometimes painful. But that’s the point, isn’t it? We’re prioritizing so we can make the best decisions possible with limited resources (which include our own time). Here’s what I would have done (and, for that matter, what I have done) in a situation like this:

1. Find a way to shrink the list to the shortest size possible. Throw out anything that hasn’t been discussed in two months or that has already been slapped with a lowish priority.
2. Publish that list to all concerned parties and make it clear that anything not on the list will not be prioritized.
3. Wait for people to scream. If they scream, add whatever item they believe is missing to the list.
4. Identify the product’s vision owner (this may be someone other than the product owner or customer) and make sure this person’s vote counts extra.
5. Gather together the stakeholders who matter and prioritize.
6. Publish the prioritization.
7. If anyone screams, register the concern and confirm that it is not based on a point overlooked by the prioritization group. If it was something the group overlooked and it has a measurable impact on the prioritized list, adjust the list accordingly.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview