Posts Tagged “cautionary tale”

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.

Comments 1 Comment »

I’ve seen quite a few teams (and not just newbie teams) grapple with this problem. The team has come up a bit short on available effort and can’t hit the release date at the end of the iteration. Just another day will do it, really. Extending your iteration a day to hit the release is a very tempting idea, but it is the very last thing you want to do. That decision simply leads the team down a road of pain. I forgot that lessen a couple months back and allowed a team to travel that road. It went something like this:

Friday the 5th

Advocate for the extension: “We’re just a little too tight this iteration. If we move the retro and planning meeting from Tuesday morning to Tuesday afternoon then we can release in the morning and hit our iteration goal.”

Me: “Okay, is there anything we can take out of the iteration backlog so that the team can still deploy on Monday?”

Advocate for the extension: “No. Everything has to go in.”

In retrospect, that statement should have set off alarm bells Read the rest of this entry »

Comments No Comments »

Newsflash. I own four small apartment buildings (well, for now, the banks own them, my wife manages them, and I’m legally and financially on the hook when bad things happen). For me, managing rental property and software development teams are not nearly as disjointed activities as they may seem. A tragedy of the commons, for example, can happen in either place.

A tragedy of the commons occurs when a public resource is overused or misused by individuals each acting in their own interest, where each instance of overuse or misuse has a greater benefit to the individual than the incremental harm it does to the public resource. Eventually, however, this can cause the resource to be spoiled beyond recovery. Hence the tragedy. For concrete examples, think overfishing or global warming.

My wife and I differentiate our properties by keeping them well-maintained. We pile on the amenities (AC, dishwashers, hardwood floors, rehabbed kitchens and baths). And, initially, we threw in freebies (free Internet access, free laundry, free applications). Well, applications are no longer free, and neither is the laundry.

Read the rest of this entry »

Comments 3 Comments »

Sometimes putting a name on something helps us to easily recognize it and more easily deal with it. Management by PowerPoint is my current name for a dreadful anti-practice that I observed at a client site some time ago. I recommend instituting this practice only if you wish to guarantee the rollout of fear, loathing, and whip cycle management across your organization. Read the rest of this entry »

Comments 2 Comments »