Comments on: I hate priorities http://chrisgagne.com/22/i-hate-priorities/ Delight customers, create value, and do good. Fri, 13 May 2011 11:16:56 +0000 hourly 1 By: Henrik Kniberg http://chrisgagne.com/22/i-hate-priorities/comment-page-1/#comment-215 Henrik Kniberg Sat, 02 Aug 2008 20:31:00 +0000 http://blog.chrisgagne.com/22/i-hate-priorities/#comment-215 I agree that it would be nice to skip the priority numbers and just have a sorted list. There is one practical problem with that though. Sometimes when working the product backlog it's nice to be able to sort the list by some other column, for example by theme or by team or by technical area. If you don't have priority numbers you are stuck with priority-based sorting, as soon as you sort by anything else you lose your priorities. So I usually use priority numbers. It is important, however, to be clear that the priority numbers are *relative*, that they are just a sorting key and not a "weighting". And also important that you provide high granularity (rather than just prio 1, 2, 3) so you don't get stuck with lots of items having the same priority. Whenever I'm in a workshop setting and stakeholders have problems prioritizing, I remove (or hide) the priority column and ask them to just sort the items. I usually print out physical cards to do this. Then, once the sorting is done, I add priority numbers 10,20, 30, 40, etc. Just like good ol' BASIC programming - leave some space in the number sequence for future items :o) I agree that it would be nice to skip the priority numbers and just have a sorted list. There is one practical problem with that though. Sometimes when working the product backlog it’s nice to be able to sort the list by some other column, for example by theme or by team or by technical area. If you don’t have priority numbers you are stuck with priority-based sorting, as soon as you sort by anything else you lose your priorities.

So I usually use priority numbers. It is important, however, to be clear that the priority numbers are *relative*, that they are just a sorting key and not a “weighting”. And also important that you provide high granularity (rather than just prio 1, 2, 3) so you don’t get stuck with lots of items having the same priority.

Whenever I’m in a workshop setting and stakeholders have problems prioritizing, I remove (or hide) the priority column and ask them to just sort the items. I usually print out physical cards to do this. Then, once the sorting is done, I add priority numbers 10,20, 30, 40, etc. Just like good ol’ BASIC programming – leave some space in the number sequence for future items :o )

]]> By: Chris Gagne http://chrisgagne.com/22/i-hate-priorities/comment-page-1/#comment-214 Chris Gagne Sun, 09 Mar 2008 18:44:59 +0000 http://blog.chrisgagne.com/22/i-hate-priorities/#comment-214 Greg, I totally agree about the stakeholder representation. I've heard that it is difficult enough getting the product manager to sit in for the sprint planning session. That said, I don't believe that a business owner needs to be present for the sprint planning session. In fact, I think it is counterproductive in the same way that a product manager trying to pair-program with the developer is counterproductive. One of the things that has worked well for me since I started working with Scrum is to hold a one-on-one meeting with the business owner a few days before the sprint planning meeting. This allows me to complete the product backlog prioritization work and ensure that I have all of my ducks in a row in anticipation of the actual sprint meeting. This also makes me much more confident that I, as the product manager, can be an effective proxy for the business needs as we begin our sprint. All this said, I think it's still the product manager's ultimate responsibility to set the priorities of all of the items in the product backlog without the business owners having to intervene in the mundane details. As I'm getting better at setting priorities, I'm finding that these meetings are becoming a "yes, that's OK" sort of confirmation meeting rather than one in which all of the details and priorities are agonized over. One of the things that makes this much easier for me is having a clear sense of the quarterly objectives and business needs. This allows me to keep the business owners as voices in my head as I go through the process of figuring out what to do next. Greg, I totally agree about the stakeholder representation. I’ve heard that it is difficult enough getting the product manager to sit in for the sprint planning session.

That said, I don’t believe that a business owner needs to be present for the sprint planning session. In fact, I think it is counterproductive in the same way that a product manager trying to pair-program with the developer is counterproductive.

One of the things that has worked well for me since I started working with Scrum is to hold a one-on-one meeting with the business owner a few days before the sprint planning meeting. This allows me to complete the product backlog prioritization work and ensure that I have all of my ducks in a row in anticipation of the actual sprint meeting. This also makes me much more confident that I, as the product manager, can be an effective proxy for the business needs as we begin our sprint.

All this said, I think it’s still the product manager’s ultimate responsibility to set the priorities of all of the items in the product backlog without the business owners having to intervene in the mundane details. As I’m getting better at setting priorities, I’m finding that these meetings are becoming a “yes, that’s OK” sort of confirmation meeting rather than one in which all of the details and priorities are agonized over.

One of the things that makes this much easier for me is having a clear sense of the quarterly objectives and business needs. This allows me to keep the business owners as voices in my head as I go through the process of figuring out what to do next.

]]> By: Greg Cohn http://chrisgagne.com/22/i-hate-priorities/comment-page-1/#comment-213 Greg Cohn Sun, 09 Mar 2008 18:30:32 +0000 http://blog.chrisgagne.com/22/i-hate-priorities/#comment-213 I agree with you. Assuming that scrum is practiced properly and there's stakeholder representation in the room, there's no need. But often the desire to impose a hard priority is a proxy for the absence of the internal customer. I agree with you. Assuming that scrum is practiced properly and there’s stakeholder representation in the room, there’s no need. But often the desire to impose a hard priority is a proxy for the absence of the internal customer.

]]>