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

Re: Product owner wont prioritise

Expand Messages
  • woynam
    If *everything* in the backlog has to be delivered (doubtful), then there are other ways to prioritize the backlog. One could prioritize based on technical
    Message 1 of 17 , Dec 3, 2010
    • 0 Attachment
      If *everything* in the backlog has to be delivered (doubtful), then there are other ways to prioritize the backlog.

      One could prioritize based on technical risk, which certainly affects business value. Are there features that are tough to implement, or have a high level of uncertainty? Implementing these first reduces the risk of surprises down the road when it may be too late.

      The backlog could be organized by theme. Stories in a single functional area should be implemented together so that if you have to pull the plug early on the project, you have cohesive sets of features.

      Are there interim deliverables? Is there a trade show that requires a demo version? If so, what makes sense to have in the demo?

      Fundamentally, we execute agile by time boxing, and varying scope. If there's a possibility (almost a given) that you won't finish by the end of 12 months, what nice-to-have features can you live without?

      Of course, I'm avoiding the core of the problem, the PO's lack of buy-in to the iterative process. You may want to start with a discussion of why on earth are you waiting *12* months to deliver a product? In today's business climate, that's an eternity. Can you really afford to spend month for *12 months* with *zero* payback?

      What could you deliver in 3 months that could start earning the company some revenue?

      Mark

      --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
      >
      > Hello
      >
      > About the project: working in 3 week sprints to deliver major new product in about 10-12 months, now in month 6. I am the PM. The PO is great in terms of product knowledge, business management etc and buys into the sprint ideals/demo's and retros. He calls the product backlog grooming and prioritisation for release planning a bit pure and will not buy into it. Rather his approach is we need all these must haves by this date, no point in prioritisation.
      >
      > Part of the issue is that the project steering group have not been briefed on how release planning works, and the fact the release burndown can be used to manage expectations and drive decision making.
      >
      > Anyway, the second issue is easily resolved if not a significant cultural hurdle. But the second cannot be crossed unless he accepts Scrum and not ScrumBut.
      >
      > Any thoughts/experience that can help engage a sensible conversation around backlog grooming/prioritisation/release planning? Anyone had similar issues.
      >
      > I am a total advocate and can appear "pure", but then I dont want to be doing ScrumBut, its a bit pointless.
      >
      > Sean
      >
    • Dave Rooney
      ... Do you have a reasonable idea of items that *should* be prioritized higher? If so, perhaps say to the Product Owner: OK, then we re going to do these
      Message 2 of 17 , Dec 3, 2010
      • 0 Attachment
        On 03/12/2010 8:25 AM, scrumnoob wrote:
        > Hello
        >
        > About the project: working in 3 week sprints to deliver major new product in about 10-12 months, now in month 6. I am the PM. The PO is great in terms of product knowledge, business management etc and buys into the sprint ideals/demo's and retros. He calls the product backlog grooming and prioritisation for release planning a bit pure and will not buy into it. Rather his approach is we need all these must haves by this date, no point in prioritisation.
        >
        > Part of the issue is that the project steering group have not been briefed on how release planning works, and the fact the release burndown can be used to manage expectations and drive decision making.
        >
        > Anyway, the second issue is easily resolved if not a significant cultural hurdle. But the second cannot be crossed unless he accepts Scrum and not ScrumBut.
        >
        > Any thoughts/experience that can help engage a sensible conversation around backlog grooming/prioritisation/release planning? Anyone had similar issues.
        >
        > I am a total advocate and can appear "pure", but then I dont want to be doing ScrumBut, its a bit pointless.
        >
        > Sean

        Do you have a reasonable idea of items that *should* be prioritized
        higher? If so, perhaps say to the Product Owner: "OK, then we're going
        to do these things first". Choose the lowest priority items first.
        Then say, "We'll leave these to the very end." Select the highest
        priority items.

        Another possible strategy is to completely randomize the order of the
        backlog items.

        The Product Owner will suddenly have a better idea of what's a higher
        priority. ;)

        Another question... prior to adopting Scrum, did the organization use a
        traditional process with a boatload of system testing in the last
        phase? If so, was that phase ever "squeezed" in order to get more
        features into a release? If so, how was the quality, or perhaps the
        better question is how much testing and rework effort had to go into
        getting the release shippable? With this information, you could ask the
        PO what features he would like done prior to the crunch period at the
        end where quality takes a hike.

        Of course, I've made a pile of assumptions about your situation.
        However, I'm hoping at least one will be true and the ideas may help! :)
        --
        Dave Rooney
        Westboro Systems
        Web: http://www.WestboroSystems.com
        Blog: http://practicalagility.blogspot.com
        Twitter: daverooneyca
      • extremeprogrammer
        I ve encountered this loads of times. When the project runs late, suddenly people find that there is a bunch of stuff they can descope. They also start wishing
        Message 3 of 17 , Dec 4, 2010
        • 0 Attachment
          I've encountered this loads of times. When the project runs late, suddenly people find that there is a bunch of stuff they can descope. They also start wishing that they had done things in a different order because some of that stuff that has been done now seems quite obviously not necessary for a first release.

          Ask him 'When the project runs late, what are you going to ask us to descope? What are you going to wish we hadn't done to give us more time to do something else?'

          Failing that, work on the items that, as well as you can tell, obviously have low value, until he starts helping.

          Also remember that there are at least two ways you can descope: you can remove requirements and you can thin down requirements.

          Lance

          --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
          >
          > Hello
          >
          > About the project: working in 3 week sprints to deliver major new product in about 10-12 months, now in month 6. I am the PM. The PO is great in terms of product knowledge, business management etc and buys into the sprint ideals/demo's and retros. He calls the product backlog grooming and prioritisation for release planning a bit pure and will not buy into it. Rather his approach is we need all these must haves by this date, no point in prioritisation.
          >
          > Part of the issue is that the project steering group have not been briefed on how release planning works, and the fact the release burndown can be used to manage expectations and drive decision making.
          >
          > Anyway, the second issue is easily resolved if not a significant cultural hurdle. But the second cannot be crossed unless he accepts Scrum and not ScrumBut.
          >
          > Any thoughts/experience that can help engage a sensible conversation around backlog grooming/prioritisation/release planning? Anyone had similar issues.
          >
          > I am a total advocate and can appear "pure", but then I dont want to be doing ScrumBut, its a bit pointless.
          >
          > Sean
          >
        • David Koontz
          I would suggest you explain the feedback loop and its value to the PO. If he expect the team to have 100% understanding of the features and get them perfect
          Message 4 of 17 , Dec 4, 2010
          • 0 Attachment

            I would suggest you explain the feedback loop and its value to the PO.   If he expect the team to have 100% understanding of the features and get them perfect the first time - he's not drawing upon his real life experiences (my guess).  Ask him what happens if the team finishes early - does the company stand to make money if they ship early?  Is there an opportunity to see quicker ROI by shipping early?  If so priority is important.  Also important if we ship late.

            I wouldn't suggest working on the low value items to get attention - this is spiteful and not productive to the relationship or the team's success.  The team is responsible, if the PO doesn't play the part - proxy for them the best everyone can.   The team many understand the value of the stories as well as the PO - they should do the best they can in priority order.

            On Dec 4, 2010, at 5:22 AM, extremeprogrammer wrote:

             

            I've encountered this loads of times. When the project runs late, suddenly people find that there is a bunch of stuff they can descope. They also start wishing that they had done things in a different order because some of that stuff that has been done now seems quite obviously not necessary for a first release.

            Ask him 'When the project runs late, what are you going to ask us to descope? What are you going to wish we hadn't done to give us more time to do something else?'

            Failing that, work on the items that, as well as you can tell, obviously have low value, until he starts helping.

            Also remember that there are at least two ways you can descope: you can remove requirements and you can thin down requirements.

            Lance

            --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
            >
            > Hello
            >
            > About the project: working in 3 week sprints to deliver major new product in about 10-12 months, now in month 6. I am the PM. The PO is great in terms of product knowledge, business management etc and buys into the sprint ideals/demo's and retros. He calls the product backlog grooming and prioritisation for release planning a bit pure and will not buy into it. Rather his approach is we need all these must haves by this date, no point in prioritisation.
            >
            > Part of the issue is that the project steering group have not been briefed on how release planning works, and the fact the release burndown can be used to manage expectations and drive decision making.
            >
            > Anyway, the second issue is easily resolved if not a significant cultural hurdle. But the second cannot be crossed unless he accepts Scrum and not ScrumBut.
            >
            > Any thoughts/experience that can help engage a sensible conversation around backlog grooming/prioritisation/release planning? Anyone had similar issues.
            >
            > I am a total advocate and can appear "pure", but then I dont want to be doing ScrumBut, its a bit pointless.
            >
            > Sean
            >


          • extremeprogrammer
            I made an assumption that the team had already attempted to explain the value of feedback to the product owner. Maybe that was the wrong assumption. I doubt
            Message 5 of 17 , Dec 5, 2010
            • 0 Attachment
              I made an assumption that the team had already attempted to explain the value of feedback to the product owner. Maybe that was the wrong assumption. I doubt it.

              I don't suggest working on the low priority items out of spite. I suggest doing it because pretty soon, the product owner will come to the team and ask why they aren't doing things in the right order. At that point, the conversation about prioritisation can be restarted.

              The problem with the team proxying for the PO is that it's likely the PO has information or authority that the team doesn't, otherwise why are they the PO? Can the team get the priorities right without this information? By carrying on as best they can in the absence of proper priority calls, they are papering over the obvious dysfunction.

              --- In scrumdevelopment@yahoogroups.com, David Koontz <davidakoontz@...> wrote:
              >
              >
              > I would suggest you explain the feedback loop and its value to the PO. If he expect the team to have 100% understanding of the features and get them perfect the first time - he's not drawing upon his real life experiences (my guess). Ask him what happens if the team finishes early - does the company stand to make money if they ship early? Is there an opportunity to see quicker ROI by shipping early? If so priority is important. Also important if we ship late.
              >
              > I wouldn't suggest working on the low value items to get attention - this is spiteful and not productive to the relationship or the team's success. The team is responsible, if the PO doesn't play the part - proxy for them the best everyone can. The team many understand the value of the stories as well as the PO - they should do the best they can in priority order.
              >
              > On Dec 4, 2010, at 5:22 AM, extremeprogrammer wrote:
              >
              > > I've encountered this loads of times. When the project runs late, suddenly people find that there is a bunch of stuff they can descope. They also start wishing that they had done things in a different order because some of that stuff that has been done now seems quite obviously not necessary for a first release.
              > >
              > > Ask him 'When the project runs late, what are you going to ask us to descope? What are you going to wish we hadn't done to give us more time to do something else?'
              > >
              > > Failing that, work on the items that, as well as you can tell, obviously have low value, until he starts helping.
              > >
              > > Also remember that there are at least two ways you can descope: you can remove requirements and you can thin down requirements.
              > >
              > > Lance
              > >
              > > --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@> wrote:
              > > >
              > > > Hello
              > > >
              > > > About the project: working in 3 week sprints to deliver major new product in about 10-12 months, now in month 6. I am the PM. The PO is great in terms of product knowledge, business management etc and buys into the sprint ideals/demo's and retros. He calls the product backlog grooming and prioritisation for release planning a bit pure and will not buy into it. Rather his approach is we need all these must haves by this date, no point in prioritisation.
              > > >
              > > > Part of the issue is that the project steering group have not been briefed on how release planning works, and the fact the release burndown can be used to manage expectations and drive decision making.
              > > >
              > > > Anyway, the second issue is easily resolved if not a significant cultural hurdle. But the second cannot be crossed unless he accepts Scrum and not ScrumBut.
              > > >
              > > > Any thoughts/experience that can help engage a sensible conversation around backlog grooming/prioritisation/release planning? Anyone had similar issues.
              > > >
              > > > I am a total advocate and can appear "pure", but then I dont want to be doing ScrumBut, its a bit pointless.
              > > >
              > > > Sean
              > > >
              > >
              > >
              >
            • scrumnoob
              Everyone, thanks for the feedback. Most of the comment you have made have gone through my mind already and all the comments have merit in their approach.
              Message 6 of 17 , Dec 6, 2010
              • 0 Attachment
                Everyone, thanks for the feedback.

                Most of the comment you have made have gone through my mind already and all the comments have merit in their approach. Interestingly I have even been tempted to start on the low priorities for all the reasons stated above.

                The PO buys in to the sprint, demo, retro principles but wants to avoid the long term thinking.

                Agree a 12 month deliver is too long, however there is a complete platform to be put in place before incremental releases can start.

                Currently I am in the space of asking the what would you descope in the last month question each time we work on the product backlog.

                The PO is defering all prioritisation to complexity/effort based judgement which is ok to a point, but for me the intial prioritisation should be business value, then we negotiate on cost/complexity/risk factors.

                Anyone, I'll keep going and see how it pans out.

                Thanks again.
              • Ron Jeffries
                Hello, scrumnoob, if in fact that is your name ... As I read this thread, I am getting a feeling of a more basic difference between you and the PO. Some of the
                Message 7 of 17 , Dec 6, 2010
                • 0 Attachment
                  Hello, scrumnoob, if in fact that is your name ...

                  As I read this thread, I am getting a feeling of a more basic
                  difference between you and the PO.

                  Some of the phrases that cause me concern:

                  "Avoid the long term thinking". Agile is /about/ minimizing long
                  term thinking. Since you are pushing the long term thinking here,
                  I'm a bit concerned.

                  "Complete platform", plus "12 month". Unless you are writing an
                  operating system, it seems like 12 months would be an awfully long
                  time to put an infrastructure in place ... at least enough in
                  place to begin building business value features.

                  "Descope in the last month". I know other people have suggested
                  this question but to a manager it sounds like giving up before one
                  has started. If we were actually DOING Scrum, we'd be shipping
                  some kind of DONE features every two weeks, and it would be
                  obvious to everyone whether they were valuable, and how many we
                  were likely to get done by the date. In this context it should be
                  easy to engage the PO. So this sounds to me as if your group may
                  not be equipped to produce DONE software every two weeks. That
                  might be the place to start, if so.

                  What do these observations make you think about?

                  Regards,

                  Ron Jeffries
                  www.XProgramming.com
                  Working in a team room reduces significant interruptions
                  by making most interruptions very insignificant.
                • scrumnoob
                  Ron - thanks for your reply. Interesting perspective as always. ... Sean! ... I think we need a mature product backlog, prioritised, so I can project forward
                  Message 8 of 17 , Dec 6, 2010
                  • 0 Attachment
                    Ron - thanks for your reply. Interesting perspective as always.

                    > Hello, scrumnoob, if in fact that is your name ...

                    Sean!

                    > "Avoid the long term thinking". Agile is /about/ minimizing long
                    > term thinking. Since you are pushing the long term thinking here,
                    > I'm a bit concerned.

                    I think we need a mature product backlog, prioritised, so I can project forward what stories we might be able to release to production at the end of future sprints and that will aid decision making/trading. The fact we are taking 12 months is a point for discussion but the real issue is that because we dont have the backlog that lends itself to a release plan we dont know if it could be 9 months as opposed to 12.

                    I take your point about long term thinking, the issue here is not willing to build a prioritised product backlog on a continuous basis and running around frantically to plan a release for an arbitary date in the future. Make sense?

                    > "Complete platform", plus "12 month". Unless you are writing an
                    > operating system, it seems like 12 months would be an awfully long
                    > time to put an infrastructure in place ... at least enough in
                    > place to begin building business value features.

                    I guess so, but then maybe not. Depends on what you are doing, how many of you there are and what it is you are trying to replace. Like I said above though, we dont know if its 12 months, date is arbitary and we have built features in the past that are not drop dead for live as the PO as not bought into prioritisation and release planning.

                    > "Descope in the last month". I know other people have suggested
                    > this question but to a manager it sounds like giving up before one
                    > has started. If we were actually DOING Scrum, we'd be shipping
                    > some kind of DONE features every two weeks, and it would be
                    > obvious to everyone whether they were valuable, and how many we
                    > were likely to get done by the date. In this context it should be
                    > easy to engage the PO. So this sounds to me as if your group may
                    > not be equipped to produce DONE software every two weeks. That
                    > might be the place to start, if so.

                    We are doing DONE every three weeks, but the product backlog has only ever really contained what was needed for the next sprint. Are we doing Scrum in total, no. See my previous comment re valuable.

                    Take your point about giving up before we started, interesting and valid manager view I agree.

                    > What do these observations make you think about?

                    We do debate frequently whether the project was specifically suitable to Scrum given the initial release size, I still think Scrum is right.

                    We have not in the past had a clear vision of what we want as a first customer offering and major assumptions at the start are now being challenged. Your point about long term thinking is interesting, you need a goal and a priority list, right?

                    I am not convincing my PO as to the value of prioritised product backlog and a release plan built of the back of it.

                    Sean



                    --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                    >
                    > Hello, scrumnoob, if in fact that is your name ...
                    >
                    > As I read this thread, I am getting a feeling of a more basic
                    > difference between you and the PO.
                    >
                    > Some of the phrases that cause me concern:
                    >
                    > "Avoid the long term thinking". Agile is /about/ minimizing long
                    > term thinking. Since you are pushing the long term thinking here,
                    > I'm a bit concerned.
                    >
                    > "Complete platform", plus "12 month". Unless you are writing an
                    > operating system, it seems like 12 months would be an awfully long
                    > time to put an infrastructure in place ... at least enough in
                    > place to begin building business value features.
                    >
                    > "Descope in the last month". I know other people have suggested
                    > this question but to a manager it sounds like giving up before one
                    > has started. If we were actually DOING Scrum, we'd be shipping
                    > some kind of DONE features every two weeks, and it would be
                    > obvious to everyone whether they were valuable, and how many we
                    > were likely to get done by the date. In this context it should be
                    > easy to engage the PO. So this sounds to me as if your group may
                    > not be equipped to produce DONE software every two weeks. That
                    > might be the place to start, if so.
                    >
                    > What do these observations make you think about?
                    >
                    > Regards,
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > Working in a team room reduces significant interruptions
                    > by making most interruptions very insignificant.
                    >
                  • Peter Stevens (cal)
                    Hi Sean, You know, it is such a classic pattern: Business can not/will not/does not set priorities, so someone in the development group (usually a 2nd line
                    Message 9 of 17 , Dec 6, 2010
                    • 0 Attachment
                      Hi Sean,

                      You know, it is such a classic pattern: Business can not/will not/does not set priorities, so someone in the development group (usually a 2nd line manager) steps in and does the dirty work. It's not really good for optimizing value, but it means prioritization does happen (and business is spared the heavy lifting and can blame development for doing it badly). Is this where your organization wants to be? Do you want to continue this pattern with Scrum?

                      In my experience, provoking the P-O by doing something stupid is not good for the ScrumMaster's job security. If you feel a need to do this, I would suggest hiring an external coach to do the dirty work ;-)

                      On a variation of the provoking theme, I once suggested to a customer that they designate a second line development manager as 'Chief Product Owner' - the idea being that the title would provoke the business people to demand that the role be located in a business group. (The manager in question decided this would be too risky, so he didn't pursue it.)

                      Perhaps by offering the P-O more positive alternatives, you can get him to come out of his shell:
                      1. One of the hard parts of Scrum is to accept short term thinking: "What should we implement this month (even though it doesn't look like we will be able to release for a year)? What features now will take us the biggest steps closer to a release?
                      2. Some people get really wrapped up on the word 'prioritize'. In Scrum, we use 'priority' as a synonym for 'sequence' - maybe sequencing will be easier for your PO to talk about than prioritizing: 'We can do any of these features in more or less any order; which one should we do first?'
                      3. You might find positive questions more useful than the negative 'descoping' question: "If you had a few working features to demo to your (customers, stakeholders, users) next month, which ones should they be?
                      Hope these ideas help...

                      Cheers,

                      Peter



                      On 6/12/10 9:40 AM, scrumnoob wrote:
                       

                      Everyone, thanks for the feedback.

                      Most of the comment you have made have gone through my mind already and all the comments have merit in their approach. Interestingly I have even been tempted to start on the low priorities for all the reasons stated above.

                      The PO buys in to the sprint, demo, retro principles but wants to avoid the long term thinking.

                      Agree a 12 month deliver is too long, however there is a complete platform to be put in place before incremental releases can start.

                      Currently I am in the space of asking the what would you descope in the last month question each time we work on the product backlog.

                      The PO is defering all prioritisation to complexity/effort based judgement which is ok to a point, but for me the intial prioritisation should be business value, then we negotiate on cost/complexity/risk factors.

                      Anyone, I'll keep going and see how it pans out.

                      Thanks again. 


                    • charles_bradley_scrum_coach
                      Sean, Whose decision was it to go to Scrum? What process did you use before? Who will get upset if you deliver zero stories next sprint? Who does the PO
                      Message 10 of 17 , Dec 6, 2010
                      • 0 Attachment
                        Sean,

                        Whose decision was it to go to Scrum? What process did you use before?

                        Who will get upset if you deliver zero stories next sprint?

                        Who does the PO report to?

                        Who do you report to? Are you the ScrumMaster?

                        My questions are along the lines of treating this issue as an impediment, so the ScrumMaster should work at resolving this, probably mostly outside of the team.

                        It sounds like you need to find the right decision maker to resolve your impediment, or to at least get "cover" for the impediment if it blows up in their face later.

                        Charles


                        --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
                        >
                        > Hello
                        >
                        > About the project: working in 3 week sprints to deliver major new product in about 10-12 months, now in month 6. I am the PM. The PO is great in terms of product knowledge, business management etc and buys into the sprint ideals/demo's and retros. He calls the product backlog grooming and prioritisation for release planning a bit pure and will not buy into it. Rather his approach is we need all these must haves by this date, no point in prioritisation.
                        >
                        > Part of the issue is that the project steering group have not been briefed on how release planning works, and the fact the release burndown can be used to manage expectations and drive decision making.
                        >
                        > Anyway, the second issue is easily resolved if not a significant cultural hurdle. But the second cannot be crossed unless he accepts Scrum and not ScrumBut.
                        >
                        > Any thoughts/experience that can help engage a sensible conversation around backlog grooming/prioritisation/release planning? Anyone had similar issues.
                        >
                        > I am a total advocate and can appear "pure", but then I dont want to be doing ScrumBut, its a bit pointless.
                        >
                        > Sean
                        >
                      • David A Barrett
                        The real problem with the PO refusing to prioritise is that it presupposes that the PB is locked down from the start of the project. In real life we know
                        Message 11 of 17 , Dec 6, 2010
                        • 0 Attachment
                          The real problem with the PO refusing to prioritise is that it presupposes that the PB is "locked down" from the start of the project.  In real life we know that this is seldom the case.  If it was so, then Waterfall would be the absolute best way to manage a software development project.  But the fact is, Waterfall fails spectacularly over and over again when applied to software development.  

                          I'd be reluctant to categorise a project without PB prioritization as "Scrum But".  I wouldn't even call it Scrum at all, because the prioritization is just too fundamental to the process.  

                          My approach would be do something silly, like actually lock down the PB.  No new features can be added, none can be changed, then wait until someone wants to do just that.  Maybe announce that the project has failed the minute the first feature takes longer to complete than estimated (I know that's not really likely to happen).  

                          Go over his head, maybe?


                          Dave Barrett


                          This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

                          Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
                        • Maurice le Rutte
                          Op 6-12-2010 09:40, scrumnoob schreef: The PO is defering all prioritisation to complexity/effort based judgement which is ok to a point, but for me the intial
                          Message 12 of 17 , Dec 9, 2010
                          • 0 Attachment

                            Op 6-12-2010 09:40, scrumnoob schreef:
                             

                            The PO is defering all prioritisation to complexity/effort based judgement which is ok to a point, but for me the intial prioritisation should be business value, then we negotiate on cost/complexity/risk factors.

                            I agree.

                            Prioritisation based on complexity and effort (aka estimated ROI) has the risk that you start to decide on individual items, while the value of the whole product is determined by the complete collection of items. A software product is not a production line where you can just produce features who then generate money, it is the total that is the value.

                            Therefore your product owner should prioritise each time on the added value to the product as it is now and how he thinks it will evolve during the remaining time to release. He should make sure that overall the optimal value is reached.

                            Just deciding on complexity/effort can lead to short term decision making and a product that in the end doesn't deliver the value it could have.

                            Maurice.
                            -- 
                            http://www.scrummaster.nl / http://twitter.com/scrumnl
                          • Geetha Anand
                            HI I m CSM, Running the Agile change . When there are multiple teams ( 3 Agile Teams) which is working towards a product, how do we do estimation? 1. Should
                            Message 13 of 17 , Dec 23, 2010
                            • 0 Attachment
                              HI
                               
                              I'm CSM, Running the Agile change .
                               
                              When there are multiple teams ( 3 Agile Teams)  which is working towards a product, how do we  do estimation?
                              1. Should the entire team of 21 be estimating the entire product backlog
                              2. Should a select few do the estimation
                              3. Should the 3 teams do estimation and then take average
                              4.  should teams take a portion of items from product backlog and estimate them and leave the remaining to rest?
                               
                               
                              which velocity  ( average??) should  be used for program level or release planning?
                               
                              Can some one help on this?
                               
                              regards
                              Geetha Anand

                              On Mon, Dec 6, 2010 at 6:51 PM, Ron Jeffries <ronjeffries@...> wrote:
                               

                              Hello, scrumnoob, if in fact that is your name ...

                              As I read this thread, I am getting a feeling of a more basic
                              difference between you and the PO.

                              Some of the phrases that cause me concern:

                              "Avoid the long term thinking". Agile is /about/ minimizing long
                              term thinking. Since you are pushing the long term thinking here,
                              I'm a bit concerned.

                              "Complete platform", plus "12 month". Unless you are writing an
                              operating system, it seems like 12 months would be an awfully long
                              time to put an infrastructure in place ... at least enough in
                              place to begin building business value features.

                              "Descope in the last month". I know other people have suggested
                              this question but to a manager it sounds like giving up before one
                              has started. If we were actually DOING Scrum, we'd be shipping
                              some kind of DONE features every two weeks, and it would be
                              obvious to everyone whether they were valuable, and how many we
                              were likely to get done by the date. In this context it should be
                              easy to engage the PO. So this sounds to me as if your group may
                              not be equipped to produce DONE software every two weeks. That
                              might be the place to start, if so.

                              What do these observations make you think about?

                              Regards,

                              Ron Jeffries
                              www.XProgramming.com
                              Working in a team room reduces significant interruptions
                              by making most interruptions very insignificant.


                            • Adam Sroka
                              My default position would be that the team that does the work should do the estimating of that work relatively close to the time that they do that work (e.g.
                              Message 14 of 17 , Dec 23, 2010
                              • 0 Attachment

                                My default position would be that the team that does the work should do the estimating of that work relatively close to the time that they do that work (e.g. in the planning meeting of the Sprint in which they take the work.)

                                I have seen a few other things work reasonably well:

                                You could have a small group made up of representatives from each team size the stories on the backlog for long term planning.

                                You could take a set of upcoming stories to one of the teams' planning meetings and have them size them. You would want to attempt to take it to the team most likely to do the work.

                                You could do long term planning based on the long term average rate at which stories are delivered as a simplification of the de facto standard Scrum approach (I recommend this.)

                                Whatever you do, the team that takes on a story always has the right to change the estimate based on the most current understanding of the problem space.

                                On Dec 23, 2010 8:26 AM, "Geetha Anand" <reachgeethaanand@...> wrote:
                                > HI
                                >
                                > I'm CSM, Running the Agile change .
                                >
                                > When there are multiple teams ( 3 Agile Teams) which is working towards a
                                > product, how do we do estimation?
                                > 1. Should the entire team of 21 be estimating the entire product backlog
                                > 2. Should a select few do the estimation
                                > 3. Should the 3 teams do estimation and then take average
                                > 4. should teams take a portion of items from product backlog and estimate
                                > them and leave the remaining to rest?
                                >
                                >
                                > which velocity ( average??) should be used for program level or release
                                > planning?
                                >
                                > Can some one help on this?
                                >
                                > regards
                                > Geetha Anand
                                >
                                > On Mon, Dec 6, 2010 at 6:51 PM, Ron Jeffries <ronjeffries@...> wrote:
                                >
                                >>
                                >>
                                >> Hello, scrumnoob, if in fact that is your name ...
                                >>
                                >> As I read this thread, I am getting a feeling of a more basic
                                >> difference between you and the PO.
                                >>
                                >> Some of the phrases that cause me concern:
                                >>
                                >> "Avoid the long term thinking". Agile is /about/ minimizing long
                                >> term thinking. Since you are pushing the long term thinking here,
                                >> I'm a bit concerned.
                                >>
                                >> "Complete platform", plus "12 month". Unless you are writing an
                                >> operating system, it seems like 12 months would be an awfully long
                                >> time to put an infrastructure in place ... at least enough in
                                >> place to begin building business value features.
                                >>
                                >> "Descope in the last month". I know other people have suggested
                                >> this question but to a manager it sounds like giving up before one
                                >> has started. If we were actually DOING Scrum, we'd be shipping
                                >> some kind of DONE features every two weeks, and it would be
                                >> obvious to everyone whether they were valuable, and how many we
                                >> were likely to get done by the date. In this context it should be
                                >> easy to engage the PO. So this sounds to me as if your group may
                                >> not be equipped to produce DONE software every two weeks. That
                                >> might be the place to start, if so.
                                >>
                                >> What do these observations make you think about?
                                >>
                                >> Regards,
                                >>
                                >> Ron Jeffries
                                >> www.XProgramming.com <http://www.xprogramming.com/>
                                >> Working in a team room reduces significant interruptions
                                >> by making most interruptions very insignificant.
                                >>
                                >>
                                >>
                              • Jussi Mononen
                                ... Hi, I have worked in an environment where several teams worked for the same product. Estimation was difficult because teams are inherently different and
                                Message 15 of 17 , Dec 23, 2010
                                • 0 Attachment
                                  On 23 December 2010 14:33, Geetha Anand <reachgeethaanand@...> wrote:
                                   

                                  HI
                                   
                                  I'm CSM, Running the Agile change .
                                   
                                  When there are multiple teams ( 3 Agile Teams)  which is working towards a product, how do we  do estimation?
                                  1. Should the entire team of 21 be estimating the entire product backlog
                                  2. Should a select few do the estimation
                                  3. Should the 3 teams do estimation and then take average
                                  4.  should teams take a portion of items from product backlog and estimate them and leave the remaining to rest?
                                   
                                   
                                  which velocity  ( average??) should  be used for program level or release planning?

                                  Hi,

                                  I have worked in an environment where several teams worked for the same product. Estimation was difficult because teams are inherently different and their velocities and estimations incomparable. What we did was that we divided the work to logical slices by functionality that would together create the product. Then the estimation of each separate backlog can be used to estimate the delivery date.

                                  Of course, and this goes without a mention, we got some extra burden of figuring out the integration of these separate slices of functionality. Continuous integration being the key and one team taking the full release responsibility was our approach. It worked out decently.

                                  Br,

                                  --
                                  "Progress doesn't come from early risers — progress is made by lazy men looking for easier ways to do things." - Robert. A. Heinlein

                                • David Koontz
                                  How large is the product backlog? I m guessing very large more than 100 stories. Use affinity estimation technique to allow the whole (21 person) team to
                                  Message 16 of 17 , Dec 24, 2010
                                  • 0 Attachment
                                    How large is the product backlog?  I'm guessing very large more than 100 stories.  Use affinity estimation technique to allow the whole (21 person) team to effort size the whole backlog.


                                    Later in the story grooming sessions that will need to be run, after the whole team understands the sizes and their relative values (a 5 pt store is "this big") then a few people (rotating who is on the "select few") may do the grooming sessions with the PO.  However this should be a technique to *estimate* and those estimates are subject to the 7 person team (squad) that will do the actual work during Sprint Planning, they may change the size at any time before commitment in the Sprint.

                                    Don't average - do estimation as a team consensus sport - there is a big difference between these in terms of human understanding and behavior.  Story sizes are relative to each other.  If one uses the common Fibonacci Sequence  - averaging would be nonsense. 

                                    The 3 teams may then pull items from the common backlog during sprint planning part 1,  where the 3 teams will decide which team does which story (joint planning with 21 people).  Then in Sprint planning part 2 (reestimation & tasking) the smaller 7 person team will reestimate the stories - taking into their candidate sprint backlog the number of stories appropriate to their unique velocity.   They will task and re estimate the stories then if all is a go (they can jointly commit to their stories) they commit - end of planning. 

                                    In this concept - you have multiple teams working on a common backlog.  I've done it and it works very well.

                                    Your teams will have similar but different velocities - that is just fine.  The joint (sum of  team velocities) velocity allows you to derive duration of the project, and do planning.

                                    David


                                    On Dec 23, 2010, at 12:16 PM, Jussi Mononen wrote:

                                     



                                    On 23 December 2010 14:33, Geetha Anand <reachgeethaanand@...> wrote:
                                     

                                    HI
                                     
                                    I'm CSM, Running the Agile change .
                                     
                                    When there are multiple teams ( 3 Agile Teams)  which is working towards a product, how do we  do estimation?
                                    1. Should the entire team of 21 be estimating the entire product backlog
                                    2. Should a select few do the estimation
                                    3. Should the 3 teams do estimation and then take average
                                    4.  should teams take a portion of items from product backlog and estimate them and leave the remaining to rest?
                                     
                                     
                                    which velocity  ( average??) should  be used for program level or release planning?

                                    Hi,

                                    I have worked in an environment where several teams worked for the same product. Estimation was difficult because teams are inherently different and their velocities and estimations incomparable. What we did was that we divided the work to logical slices by functionality that would together create the product. Then the estimation of each separate backlog can be used to estimate the delivery date.

                                    Of course, and this goes without a mention, we got some extra burden of figuring out the integration of these separate slices of functionality. Continuous integration being the key and one team taking the full release responsibility was our approach. It worked out decently.

                                    Br,

                                    --
                                    "Progress doesn't come from early risers — progress is made by lazy men looking for easier ways to do things." - Robert. A. Heinlein



                                  Your message has been successfully submitted and would be delivered to recipients shortly.