Scrum Tip: Be wary of how you prioritize

Being a product owner is hard. Making sure you achieve the proper balance of tasks across different stake holders in a product isn’t easy. Support and operations need certain enhancements that make servicing the customer easier, while the business needs to advance with new features as well, and the designer wants to make the user twice as happy by tweaking a few things. All good things, that require good prioritization in order to make a successful product.

So be wary of how you prioritize.

A while back, I started noticing something odd about my priorities. The following scenario kept happening:

  • Monday - Someone asks for feature A

  • Tuesday - Someone asks for feature B

  • Wednesday - Someone asks for feature C

  • Thursday - Someone asks for feature D

On Friday, during sprint planning, the priorities end up being D, C, B, then A. I was allowing the most recent, and loudest, voice win and not some sort of metrics. I didn’t have enough info to effectively weigh A vs D. I was flying blind and trusting the loudest voice, which isn’t a good thing.

When requests to the product backlog come in, don’t take them blindly. Challenge the requester. Ask if they really need this. Push back. Dig into why a request is needed, so weighing it against other requests is possible. If you aren’t challenging your stake holders, you will end up with a backlog miles long that is very hard to prioritize. If nothing else, the process will help you better understand the request.

This is about where I am today. My next step is to follow Dharmesh’s advice, and start weighing different attributes about each request. This way changing priorities don’t completely change the product backlog, they just change which attributes we value the most.

Let me know any tips you might have on prioritization.