Loading ...
Sorry, an error occurred while loading the content.

Backlog Priority

Expand Messages
  • JIM WIESEN
    I ve been looking at the sample backlog items in the Scrum methodology document( section 1.2 ) and I m seeing that priority is given in a 1-9 format. I don t
    Message 1 of 6 , Jun 17, 2003
    • 0 Attachment

      I've been looking at the sample backlog items in the Scrum methodology document( section 1.2 ) and I'm seeing that priority is given in a 1-9 format. I don't have an issue with that( except that it may be to many levels ), but should all of the #1's also be ordered? It doesn't make any mention of that. If I have 90 days worth of #1 priority items and we are in a planning meeting and the number #1 items are not also ordered distinctly by priority( 1, 2, 3, 4...N, N+1...) then is it not implied that the team can pick any of the #1 items that they want? Is this acceptable? This seems to contradict the idea that the Product Owner decides what is built and puts some of that in the hands of the team since they could just pick any 30 days worth of backlog with #1 priority. I'm thinking that I would prefer to just order the entire list from 1 to N and drop the current priority stuff. That way, the most important items are just those at the very top. Priority is then just implied to be top down and there is no need for explicit priority groupings.     

       

      -------------------------------------------------------------------------------

      Jim Wiesen

      Software Architect - .NET Solutions

      Long & Foster Real Estate

      jwiesen@...

      http://www.longandfoster.com

       

    • Mike Cohn
      This problem points out what I think is the biggest advantage of XP style story writing on physical index cards-they are easy to sort into a forced, discrete
      Message 2 of 6 , Jun 17, 2003
      • 0 Attachment

        This problem points out what I think is the biggest advantage of XP style story writing on physical index cards—they are easy to sort into a forced, discrete order. (Yes you can pile them in groups but when you stack the whole deck up they can/should be in a forced priority order.)

         

        Using Excel or other tools it’s a little harder to do this—yeah you can move Excel rows around but it gets tedious.

         

        I use a 5-level prioritization: Very High, High, Normal, Low, Very Low and ask the Product Owner to put them into “roughly priority order” within each group. That is, if there are 30 Very High items then #1 is more important than #30 but #1 and #2 may be out of order; in any event 1 and 2 are so close in priority that further refinement of their order doesn’t matter.

         

        During the Sprint Planning Meeting the Product Owner starts at the top and talks to us about the stories (we use stories as our requirements items). She works down the list until everyone starts saying “OK, we’ve definitely talked about more than enough for this sprint.” We typically go about 50% deeper than necessary. That is, assuming all stories are the same length, if we could do 20 in a sprint we’d talk about 30. If after we’ve talked about 30 and we start to decide it’s enough the Product Owner decides that she wants to talk about a few others (lower on the list, somewhat incorrectly) she moves them up. Maybe we have 34 stories at that point. The team then figures out which they’ll do in the sprint. That almost certainly won’t be 1-20. There may be synergies with some in the 21-34 range that get pulled up and the ideal programmer for 17 and 18 is also the ideal programmer for 1-4 so we hold off on 17-18 till next sprint but bring in 24-29 instead, etc.

         

        This goes a bit against XP’s Planning Game which would be much more rigorously start at the top and work down. In practice I suspect they skip an occasional story (17 is too big to fit but 21 fits so they do 1-16, 18-21, skipping 17; or perhaps 21 is so close to 20 it gets in but 19 is left out).

         

        I think in Scrum we acknowledge the same idea as XP that we don’t want to do future work any earlier than necessary since it may not be valued later. But, we acknowledge that sometimes doing work that would otherwise barely miss is worth doing instead if it fits better with the other work or with the people involved. Another example: Suppose I’ve got a really complex chunk of 50,000 lines of code as a component in my system. I don’t have to go anywhere near it unless I do story 17. Story 21 is the same size but is in an area I’m already going to be all over and will have to test completely anyway. I think it’s easily justified to do 21 instead of 17.

         

        --Mike

         

         

        -----Original Message-----
        From: JIM WIESEN [mailto:jwiesen@...]
        Sent: Tuesday, June 17, 2003 9:55 AM
        To: 'scrumdevelopment@yahoogroups.com'
        Subject: [scrumdevelopment] Backlog Priority

         

        I've been looking at the sample backlog items in the Scrum methodology document( section 1.2 ) and I'm seeing that priority is given in a 1-9 format. I don't have an issue with that( except that it may be to many levels ), but should all of the #1's also be ordered? It doesn't make any mention of that. If I have 90 days worth of #1 priority items and we are in a planning meeting and the number #1 items are not also ordered distinctly by priority( 1, 2, 3, 4...N, N+1...) then is it not implied that the team can pick any of the #1 items that they want? Is this acceptable? This seems to contradict the idea that the Product Owner decides what is built and puts some of that in the hands of the team since they could just pick any 30 days worth of backlog with #1 priority. I'm thinking that I would prefer to just order the entire list from 1 to N and drop the current priority stuff. That way, the most important items are just those at the very top. Priority is then just implied to be top down and there is no need for explicit priority groupings.     

         

        -------------------------------------------------------------------------------

        Jim Wiesen

        Software Architect - .NET Solutions

        Long & Foster Real Estate

        jwiesen@...

        http://www.longandfoster.com

         



        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • Tony Homer
        Our product backlog evolved from an access-based buglog. The product owner is responsible for prioritizing the backlog: we just added a field called priority
        Message 3 of 6 , Jun 17, 2003
        • 0 Attachment
          Our product backlog evolved from an access-based buglog.  The product owner is responsible for prioritizing the backlog: we just added a field called priority and exposed it in a form they can use. 
           
          It took a long time to get the product owner to cooperate fully with prioritization.  When we started, there was a lot of argument along the lines of "everything in this list is really important and needs to be done by MM/DD/YYYY, so I can't prioritize it", but eventually we have arrived at the point where the Product Owner has prioritized most of the backlog from 0.1 to 250 or so (fractional priorities allow simple reprioritization: the product owner used to feel compelled to renumber everything).  There are still occasions where 2 items share a priority, but these are cases where either the tasks are co-dependent or where the product owner feels the tasks are of equivalent importance and would like the development team to prioritize based on efficiency.
           
          There are other issues regarding priority that need to be addressed using good communications with the Product Owner.  For example, the Product Owner may want to reprioritize based on cost (both bumping up items that are cheaper than expected and bumping down items that are more expensive).  It doesn't always make sense to approach tasks in strict priority order, because although my core team is composed of generalists, they are each most familiar with particular areas of the system.  We have had situations where all of the highest priority tasks would best be done by the same individual.  In these cases, I have explained to the product owner during the sprint planning session that it would be most effective to defer some of the high-priority tasks to a future sprint.  Hope that made sense...
           
          Tony
           
           -----Original Message-----
          From: Mike Cohn [mailto:mike@...]
          Sent: Tuesday, June 17, 2003 12:33 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Backlog Priority

          This problem points out what I think is the biggest advantage of XP style story writing on physical index cards-they are easy to sort into a forced, discrete order. (Yes you can pile them in groups but when you stack the whole deck up they can/should be in a forced priority order.)

           

          Using Excel or other tools it's a little harder to do this-yeah you can move Excel rows around but it gets tedious.

           

          I use a 5-level prioritization: Very High, High, Normal, Low, Very Low and ask the Product Owner to put them into "roughly priority order" within each group. That is, if there are 30 Very High items then #1 is more important than #30 but #1 and #2 may be out of order; in any event 1 and 2 are so close in priority that further refinement of their order doesn't matter.

           

          During the Sprint Planning Meeting the Product Owner starts at the top and talks to us about the stories (we use stories as our requirements items). She works down the list until everyone starts saying "OK, we've definitely talked about more than enough for this sprint." We typically go about 50% deeper than necessary. That is, assuming all stories are the same length, if we could do 20 in a sprint we'd talk about 30. If after we've talked about 30 and we start to decide it's enough the Product Owner decides that she wants to talk about a few others (lower on the list, somewhat incorrectly) she moves them up. Maybe we have 34 stories at that point. The team then figures out which they'll do in the sprint. That almost certainly won't be 1-20. There may be synergies with some in the 21-34 range that get pulled up and the ideal programmer for 17 and 18 is also the ideal programmer for 1-4 so we hold off on 17-18 till next sprint but bring in 24-29 instead, etc.

           

          This goes a bit against XP's Planning Game which would be much more rigorously start at the top and work down. In practice I suspect they skip an occasional story (17 is too big to fit but 21 fits so they do 1-16, 18-21, skipping 17; or perhaps 21 is so close to 20 it gets in but 19 is left out).

           

          I think in Scrum we acknowledge the same idea as XP that we don't want to do future work any earlier than necessary since it may not be valued later. But, we acknowledge that sometimes doing work that would otherwise barely miss is worth doing instead if it fits better with the other work or with the people involved. Another example: Suppose I've got a really complex chunk of 50,000 lines of code as a component in my system. I don't have to go anywhere near it unless I do story 17. Story 21 is the same size but is in an area I'm already going to be all over and will have to test completely anyway. I think it's easily justified to do 21 instead of 17.

           

          --Mike

           

           

          -----Original Message-----
          From: JIM WIESEN [mailto:jwiesen@...]
          Sent: Tuesday, June 17, 2003 9:55 AM
          To: 'scrumdevelopment@yahoogroups.com'
          Subject: [scrumdevelopment] Backlog Priority

           

          I've been looking at the sample backlog items in the Scrum methodology document( section 1.2 ) and I'm seeing that priority is given in a 1-9 format. I don't have an issue with that( except that it may be to many levels ), but should all of the #1's also be ordered? It doesn't make any mention of that. If I have 90 days worth of #1 priority items and we are in a planning meeting and the number #1 items are not also ordered distinctly by priority( 1, 2, 3, 4...N, N+1...) then is it not implied that the team can pick any of the #1 items that they want? Is this acceptable? This seems to contradict the idea that the Product Owner decides what is built and puts some of that in the hands of the team since they could just pick any 30 days worth of backlog with #1 priority. I'm thinking that I would prefer to just order the entire list from 1 to N and drop the current priority stuff. That way, the most important items are just those at the very top. Priority is then just implied to be top down and there is no need for explicit priority groupings.     

           

          -------------------------------------------------------------------------------

          Jim Wiesen

          Software Architect - .NET Solutions

          Long & Foster Real Estate

          jwiesen@...

          http://www.longandfoster.com

           



        • JIM WIESEN
          That is my current problem. Scrum is very new to us, and the majority of our backlog is a number 1 priortiy. Gotta have it. I’m working on this problem,
          Message 4 of 6 , Jun 17, 2003
          • 0 Attachment

            That is my current problem. Scrum is very new to us, and the majority of our backlog is a number 1 priortiy. Gotta have it. Im working on this problem, but I needed a solution in the meantime.

             

            I have found that I can easily reprioritize the backlog in Excel by using a similar solution. We can use numerics( including non-integers) as the priority and resort the list. I can then use a simple N+1 formula and convert all of them back to integers so that things dont get too messy. Then, if we need to slide item 10 between items 3 and 4, it can be changed to something like 3.5. Then when the conversion occurs, 3 stays, 3.5 becomes 4, and so on.  

             

            -----Original Message-----
            From: Tony Homer [mailto:tony_homer@...]
            Sent: Tuesday, June 17, 2003 1:22 PM
            To: 'scrumdevelopment@yahoogroups.com'
            Subject: RE: [scrumdevelopment] Backlog Priority

             

            Our product backlog evolved from an access-based buglog.  The product owner is responsible for prioritizing the backlog: we just added a field called priority and exposed it in a form they can use. 

             

            It took a long time to get the product owner to cooperate fully with prioritization.  When we started, there was a lot of argument along the lines of "everything in this list is really important and needs to be done by MM/DD/YYYY, so I can't prioritize it", but eventually we have arrived at the point where the Product Owner has prioritized most of the backlog from 0.1 to 250 or so (fractional priorities allow simple reprioritization: the product owner used to feel compelled to renumber everything).  There are still occasions where 2 items share a priority, but these are cases where either the tasks are co-dependent or where the product owner feels the tasks are of equivalent importance and would like the development team to prioritize based on efficiency.

             

            There are other issues regarding priority that need to be addressed using good communications with the Product Owner.  For example, the Product Owner may want to reprioritize based on cost (both bumping up items that are cheaper than expected and bumping down items that are more expensive).  It doesn't always make sense to approach tasks in strict priority order, because although my core team is composed of generalists, they are each most familiar with particular areas of the system.  We have had situations where all of the highest priority tasks would best be done by the same individual.  In these cases, I have explained to the product owner during the sprint planning session that it would be most effective to defer some of the high-priority tasks to a future sprint.  Hope that made sense...

             

            Tony

             

             -----Original Message-----
            From: Mike Cohn [mailto:mike@...]
            Sent: Tuesday, June 17, 2003 12:33 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] Backlog Priority

            This problem points out what I think is the biggest advantage of XP style story writing on physical index cards-they are easy to sort into a forced, discrete order. (Yes you can pile them in groups but when you stack the whole deck up they can/should be in a forced priority order.)

             

            Using Excel or other tools it's a little harder to do this-yeah you can move Excel rows around but it gets tedious.

             

            I use a 5-level prioritization: Very High, High, Normal, Low, Very Low and ask the Product Owner to put them into "roughly priority order" within each group. That is, if there are 30 Very High items then #1 is more important than #30 but #1 and #2 may be out of order; in any event 1 and 2 are so close in priority that further refinement of their order doesn't matter.

             

            During the Sprint Planning Meeting the Product Owner starts at the top and talks to us about the stories (we use stories as our requirements items). She works down the list until everyone starts saying "OK, we've definitely talked about more than enough for this sprint." We typically go about 50% deeper than necessary. That is, assuming all stories are the same length, if we could do 20 in a sprint we'd talk about 30. If after we've talked about 30 and we start to decide it's enough the Product Owner decides that she wants to talk about a few others (lower on the list, somewhat incorrectly) she moves them up. Maybe we have 34 stories at that point. The team then figures out which they'll do in the sprint. That almost certainly won't be 1-20. There may be synergies with some in the 21-34 range that get pulled up and the ideal programmer for 17 and 18 is also the ideal programmer for 1-4 so we hold off on 17-18 till next sprint but bring in 24-29 instead, etc.

             

            This goes a bit against XP's Planning Game which would be much more rigorously start at the top and work down. In practice I suspect they skip an occasional story (17 is too big to fit but 21 fits so they do 1-16, 18-21, skipping 17; or perhaps 21 is so close to 20 it gets in but 19 is left out).

             

            I think in Scrum we acknowledge the same idea as XP that we don't want to do future work any earlier than necessary since it may not be valued later. But, we acknowledge that sometimes doing work that would otherwise barely miss is worth doing instead if it fits better with the other work or with the people involved. Another example: Suppose I've got a really complex chunk of 50,000 lines of code as a component in my system. I don't have to go anywhere near it unless I do story 17. Story 21 is the same size but is in an area I'm already going to be all over and will have to test completely anyway. I think it's easily justified to do 21 instead of 17.

             

            --Mike

             

             

            -----Original Message-----
            From: JIM WIESEN [mailto:jwiesen@...]
            Sent: Tuesday, June 17, 2003 9:55 AM
            To: 'scrumdevelopment@yahoogroups.com'
            Subject: [scrumdevelopment] Backlog Priority

             

            I've been looking at the sample backlog items in the Scrum methodology document( section 1.2 ) and I'm seeing that priority is given in a 1-9 format. I don't have an issue with that( except that it may be to many levels ), but should all of the #1's also be ordered? It doesn't make any mention of that. If I have 90 days worth of #1 priority items and we are in a planning meeting and the number #1 items are not also ordered distinctly by priority( 1, 2, 3, 4...N, N+1...) then is it not implied that the team can pick any of the #1 items that they want? Is this acceptable? This seems to contradict the idea that the Product Owner decides what is built and puts some of that in the hands of the team since they could just pick any 30 days worth of backlog with #1 priority. I'm thinking that I would prefer to just order the entire list from 1 to N and drop the current priority stuff. That way, the most important items are just those at the very top. Priority is then just implied to be top down and there is no need for explicit priority groupings.     

             

            -------------------------------------------------------------------------------

            Jim Wiesen

            Software Architect - .NET Solutions

            Long & Foster Real Estate

            jwiesen@...

            http://www.longandfoster.com

             

             



            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          • Bryan Zarnett
            ... Hi Jim, For your current release do you have a vision that defines the scope? I often find that by providing a goal for the release (not the iteration)
            Message 5 of 6 , Jun 17, 2003
            • 0 Attachment
              On Tuesday, June 17, 2003, at 02:01PM, JIM WIESEN <jwiesen@...> wrote:

              >That is my current problem. Scrum is very new to us, and the majority of our backlog is a number 1 priortiy. Gotta have it. Im working on this problem, but I needed a solution in the meantime.

              Hi Jim,

              For your current release do you have a vision that defines the scope? I often find that by providing a goal for the release (not the iteration) people can view the list of what has to be done and prioritize it accordingly. If they don't have this goal, they are not sure of their end point and thus everything is Mandatory.

              As well, have you tried using words instead of numbers. For example:

              Mandatory - can't ship the release without it
              Required - can ship the release without it but we need it right after
              Nice to have - if you have time could you...

              Do you have a single individual defining the priorities or is it a group of people - do you have a business advocate that gets input from everyone else and then makes the best choices for the business in terms of priority in regards to the scope of the release, return on investment, and return on expectations?

              Having the business advocate thing in terms of meeting scope, ROI, and expectations changes the perspectives and gives them a list to base their values upon.

              Cheers,
              Bryan



              I have found that I can easily reprioritize the backlog in Excel by using a similar solution. We can use numerics( including non-integers) as the priority and resort the list. I can then use a simple N+1 formula and convert all of them back to integers so that things dont get too messy. Then, if we need to slide item 10 between items 3 and 4, it can be changed to something like 3.5. Then when the conversion occurs, 3 stays, 3.5 becomes 4, and so on.
            • JIM WIESEN
              We do not have a single vision for the product. Things are coming in from all sides, but I do have 1 person taking this all in for the team. We have deemed
              Message 6 of 6 , Jun 17, 2003
              • 0 Attachment
                We do not have a single vision for the product. Things are coming in from
                all sides, but I do have 1 person taking this all in for the team. We have
                deemed this person( a business analyst ) our product owner. She basically
                builds backlog from all of the requests from departments within the
                organization. HOWEVER, she does not get to prioritize things. That falls to
                my director. He is simply too busy to be a valuable product owner, but there
                is a demand that he decides what gets built and thus, he is the one that
                prioritizes the backlog. The analyst is the day-to-day product owner, but
                when sprint planning time comes around, we( scrum master and the analyst)
                present the backlog to him for understanding and prioritization. He then
                applies his own political agenda and decides on the priorities. ROI is
                neither calculated nor used in decision making ( most of the time ). The
                majority of decisions are based on political posturing. I just try to stay
                out of the way so I don't get shot.

                I should also say that we are doing production releases every single sprint.
                We always lose time for such things as regression testing, training, etc,
                but management is willing to pay this price for releasing new product every
                sprint. They already think that 30 days is an eternity. This release
                schedule is also non-negotiable.


                -----Original Message-----
                From: Bryan Zarnett [mailto:bzarnett@...]
                Sent: Tuesday, June 17, 2003 2:19 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] Backlog Priority


                On Tuesday, June 17, 2003, at 02:01PM, JIM WIESEN
                <jwiesen@...> wrote:

                >That is my current problem. Scrum is very new to us, and the majority of
                our backlog is a number 1 priortiy. Gotta have it. I'm working on this
                problem, but I needed a solution in the meantime.

                Hi Jim,

                For your current release do you have a vision that defines the scope? I
                often find that by providing a goal for the release (not the iteration)
                people can view the list of what has to be done and prioritize it
                accordingly. If they don't have this goal, they are not sure of their end
                point and thus everything is Mandatory.

                As well, have you tried using words instead of numbers. For example:

                Mandatory - can't ship the release without it
                Required - can ship the release without it but we need it right after
                Nice to have - if you have time could you...

                Do you have a single individual defining the priorities or is it a group of
                people - do you have a business advocate that gets input from everyone else
                and then makes the best choices for the business in terms of priority in
                regards to the scope of the release, return on investment, and return on
                expectations?

                Having the business advocate thing in terms of meeting scope, ROI, and
                expectations changes the perspectives and gives them a list to base their
                values upon.

                Cheers,
                Bryan



                I have found that I can easily reprioritize the backlog in Excel by using a
                similar solution. We can use numerics( including non-integers) as the
                priority and resort the list. I can then use a simple N+1 formula and
                convert all of them back to integers so that things don't get too messy.
                Then, if we need to slide item 10 between items 3 and 4, it can be changed
                to something like 3.5. Then when the conversion occurs, 3 stays, 3.5 becomes
                4, and so on.



                To Post a message, send it to: scrumdevelopment@...
                To Unsubscribe, send a blank message to:
                scrumdevelopment-unsubscribe@...

                Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              Your message has been successfully submitted and would be delivered to recipients shortly.