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

Having the Product Owner in team Estimation Meetings

Expand Messages
  • Robert Molchon
    Hello fellow scrum enthusiasts, I was wondering what people thought of having the Product Owner attend the Team s product backlog estimation meetings? On one
    Message 1 of 18 , Jan 12, 2011
    • 0 Attachment

      Hello fellow scrum enthusiasts,

       

      I was wondering what people thought of having the Product Owner attend the Team’s product backlog estimation meetings?

       

      On one hand it can be a good thing, as the Product Owner can help provide color and answer questions regarding the meaning of the backlog items that the team is estimating. This is what we currently do. Each team has a weekly backlog estimation meeting to go through any unestimated items on the backlog and the Product Owner generally attends.

       

      On the other hand, I have noticed that being in the estimation meeting can lead to less well written backlog items since the PO knows that he or she will be in the meeting to explain it to the team.

       

      What, dear friends, do you think?

       

      Thanks

      Rob

       

       

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

      Rob Molchon

      Vice-President, Engineering

       

      Unicast
      205 West 39th Street 16th Floor

      New York, NY 10018

      Office: 212.201.0856

      Cell: 917.214.0551

      Fax: 212.201.0801

      www.unicast.com

       

    • André Heijstek
      Hi Rob, Your points are right. Let me add a few thoughts. If the PO is not only attending the estimation meetings, but also frequently available to the team
      Message 2 of 18 , Jan 12, 2011
      • 0 Attachment
        Hi Rob,

        Your points are right. Let me add a few thoughts.
        If the PO is not only attending the estimation meetings, but also frequently available to the team during the sprint, then the disadvantage of not-so-well-written user stories is not so big.
        Another risk might be that the PO wants to influence the estimates. Non-technical people who really want to have a feature, and want to pay almost nothing might push the team "this can't be 5 story points, 2 points should be enough to build this!". Obviously, that should not happen. Some PO's get into this behaviour, others do respect the team.

        Regards, André

        andre.heijstek@...
        www.improvementfocus.nl
        twitter: @andreheijstek
        Mobile: +31 648476451
        Marga Klompéstraat 23
        2805 CZ Gouda
        The Netherlands

        On 12 jan 2011, at 21:53, Robert Molchon wrote:

         

        Hello fellow scrum enthusiasts,

         

        I was wondering what people thought of having the Product Owner attend the Team’s product backlog estimation meetings?

         

        On one hand it can be a good thing, as the Product Owner can help provide color and answer questions regarding the meaning of the backlog items that the team is estimating. This is what we currently do. Each team has a weekly backlog estimation meeting to go through any unestimated items on the backlog and the Product Owner generally attends.

         

        On the other hand, I have noticed that being in the estimation meeting can lead to less well written backlog items since the PO knows that he or she will be in the meeting to explain it to the team.

         

        What, dear friends, do you think?

         

        Thanks

        Rob

         

         

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

        Rob Molchon

        Vice-President, Engineering

         

        Unicast
        205 West 39th Street 16th Floor

        New York, NY 10018

        Office: 212.201.0856

        Cell: 917.214.0551

        Fax: 212.201.0801

        www.unicast.com

         



      • Charles Bradley - Scrum Coach, CSM, PSM I
        +1 to Andre s comments. Also: * I ve never heard of a backlog grooming meeting where the PO was not present (either in person or by phone/video conference,
        Message 3 of 18 , Jan 12, 2011
        • 0 Attachment
          +1 to Andre's comments.

          Also:
          • I've never heard of a backlog grooming meeting where the PO was not present (either in person or by phone/video conference, etc).
          • Yes, the Dev Team owns the estimates, and the PO should not try to influence them. 
          • Having a PO or team wanting to "go mostly verbal" can be a good thing or a bad thing, depending on a lot of factors. 
          I would think the key questions about whether to document more or less(in this context) are:
          1.  Is it likely that someone(PO or dev team member) will not remember the "conversation" correctly from now until the backlog item is accepted by the PO?
          2.  If someone doesn't remember the conversation detail, does it take ever take longer than about 60 seconds to get an answer from someone who does remember correctly?

          If you answer Yes to either one, then you should probably document more, but your team should strive to improve verbal communication frequency so that they can eventually document less.

          Either way, you should strive to go more verbal, so long as you can do so without affecting development efficiency and quality.

          I cover some of this in my "User Story Traps" post here(Be sure and see Trap #'s 10-14):
          http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/
          (Article assumes User Stories for PBI's, but you could apply some of the same principles to other kinds of PBI's)

          Charles



          From: André Heijstek <andre.heijstek@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Wed, January 12, 2011 2:02:38 PM
          Subject: Re: [scrumdevelopment] Having the Product Owner in team Estimation Meetings

           

          Hi Rob,


          Your points are right. Let me add a few thoughts.
          If the PO is not only attending the estimation meetings, but also frequently available to the team during the sprint, then the disadvantage of not-so-well-written user stories is not so big.
          Another risk might be that the PO wants to influence the estimates. Non-technical people who really want to have a feature, and want to pay almost nothing might push the team "this can't be 5 story points, 2 points should be enough to build this!". Obviously, that should not happen. Some PO's get into this behaviour, others do respect the team.

        • Adam Sroka
          It s probably because I am an XP guy but this whole idea of inviting people to some meetings and excluding them from others for some purpose is very odd to
          Message 4 of 18 , Jan 12, 2011
          • 0 Attachment
            It's probably because I am an "XP guy" but this whole idea of inviting people to some meetings and excluding them from others for some purpose is very odd to me. I want as many interested parties in the room as I can get, within reason. 

            I can't imagine breaking down work and estimating it without having someone in the room to answer the "what does this mean?" questions. If we aren't asking those kinds of questions then how accurate can our estimates be? I would think that the PO must be in the room for these kinds of questions and having a user or two on hand would be good as well. 

            On Wed, Jan 12, 2011 at 2:07 PM, Charles Bradley - Scrum Coach, CSM, PSM I <chuck-lists2@...> wrote:
             

            +1 to Andre's comments.

            Also:
            • I've never heard of a backlog grooming meeting where the PO was not present (either in person or by phone/video conference, etc).
            • Yes, the Dev Team owns the estimates, and the PO should not try to influence them. 
            • Having a PO or team wanting to "go mostly verbal" can be a good thing or a bad thing, depending on a lot of factors. 
            I would think the key questions about whether to document more or less(in this context) are:
            1.  Is it likely that someone(PO or dev team member) will not remember the "conversation" correctly from now until the backlog item is accepted by the PO?
            2.  If someone doesn't remember the conversation detail, does it take ever take longer than about 60 seconds to get an answer from someone who does remember correctly?

            If you answer Yes to either one, then you should probably document more, but your team should strive to improve verbal communication frequency so that they can eventually document less.

            Either way, you should strive to go more verbal, so long as you can do so without affecting development efficiency and quality.

            I cover some of this in my "User Story Traps" post here(Be sure and see Trap #'s 10-14):
            http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/
            (Article assumes User Stories for PBI's, but you could apply some of the same principles to other kinds of PBI's)

            Charles



            From: André Heijstek <andre.heijstek@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Wed, January 12, 2011 2:02:38 PM
            Subject: Re: [scrumdevelopment] Having the Product Owner in team Estimation Meetings

             

            Hi Rob,


            Your points are right. Let me add a few thoughts.
            If the PO is not only attending the estimation meetings, but also frequently available to the team during the sprint, then the disadvantage of not-so-well-written user stories is not so big.
            Another risk might be that the PO wants to influence the estimates. Non-technical people who really want to have a feature, and want to pay almost nothing might push the team "this can't be 5 story points, 2 points should be enough to build this!". Obviously, that should not happen. Some PO's get into this behaviour, others do respect the team.


          • JackM
            I think it s a must. Whenever i have participated in these sessions there s always questions that come up. They do not participate in the voting, they re their
            Message 5 of 18 , Jan 12, 2011
            • 0 Attachment
              I think it's a must. Whenever i have participated in these sessions there's always questions that come up. They do not participate in the voting, they're their to add input to the discussions.

              Incidentally I am of the opinion that more participation in all areas and aspects of Scrum by the product owner is a good thing!

              Jack
              www.agilebuddy.com
              blog.agilebuddy.com

              --- In scrumdevelopment@yahoogroups.com, Robert Molchon <rob.molchon@...> wrote:
              >
              > Hello fellow scrum enthusiasts,
              >
              > I was wondering what people thought of having the Product Owner attend the Team's product backlog estimation meetings?
              >
              > On one hand it can be a good thing, as the Product Owner can help provide color and answer questions regarding the meaning of the backlog items that the team is estimating. This is what we currently do. Each team has a weekly backlog estimation meeting to go through any unestimated items on the backlog and the Product Owner generally attends.
              >
              > On the other hand, I have noticed that being in the estimation meeting can lead to less well written backlog items since the PO knows that he or she will be in the meeting to explain it to the team.
              >
              > What, dear friends, do you think?
              >
              > Thanks
              > Rob
              >
              >
              > ------------------------------------
              > Rob Molchon
              > Vice-President, Engineering
              >
              > Unicast
              > 205 West 39th Street 16th Floor
              > New York, NY 10018
              > Office: 212.201.0856
              > Cell: 917.214.0551
              > Fax: 212.201.0801
              > www.unicast.com<http://www.unicast.com/>
              >
            • Charles Bradley - Scrum Coach, CSM, PSM I
              ... ++1, so long as the PO only plays the (correct) PO role in that situation. cb ________________________________ From: JackM To:
              Message 6 of 18 , Jan 12, 2011
              • 0 Attachment
                > Incidentally I am of the opinion that more participation in all areas and aspects of Scrum by the product owner is a good thing!

                ++1, so long as the PO only plays the (correct) PO role in that situation. 

                cb



                From: JackM <jack@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Wed, January 12, 2011 4:08:18 PM
                Subject: [scrumdevelopment] Re: Having the Product Owner in team Estimation Meetings

                 

                I think it's a must. Whenever i have participated in these sessions there's always questions that come up. They do not participate in the voting, they're their to add input to the discussions.

                Incidentally I am of the opinion that more participation in all areas and aspects of Scrum by the product owner is a good thing!

                Jack
                www.agilebuddy.com
                blog.agilebuddy.com

                --- In scrumdevelopment@yahoogroups.com, Robert Molchon <rob.molchon@...> wrote:
                >
                > Hello fellow scrum enthusiasts,
                >
                > I was wondering what people thought of having the Product Owner attend the Team's product backlog estimation meetings?
                >
                > On one hand it can be a good thing, as the Product Owner can help provide color and answer questions regarding the meaning of the backlog items that the team is estimating. This is what we currently do. Each team has a weekly backlog estimation meeting to go through any unestimated items on the backlog and the Product Owner generally attends.
                >
                > On the other hand, I have noticed that being in the estimation meeting can lead to less well written backlog items since the PO knows that he or she will be in the meeting to explain it to the team.
                >
                > What, dear friends, do you think?
                >
                > Thanks
                > Rob
                >
                >
                > ------------------------------------
                > Rob Molchon
                > Vice-President, Engineering
                >
                > Unicast
                > 205 West 39th Street 16th Floor
                > New York, NY 10018
                > Office: 212.201.0856
                > Cell: 917.214.0551
                > Fax: 212.201.0801
                > www.unicast.com<http://www.unicast.com/>
                >

              • alex.armstrong
                Rob, You have received some good answers here. I won t reiterate them, but I will add a comment about your statement: ...a weekly backlog estimation meeting
                Message 7 of 18 , Jan 13, 2011
                • 0 Attachment
                  Rob,

                  You have received some good answers here. I won't reiterate them, but I will add a comment about your statement: "...a weekly backlog estimation meeting to go through any unestimated items on the backlog..."

                  Unless your backlog is only 2 Sprints deep, be sure you aren't wasting team time on needless estimation of PBIs that may never be built. Instead of a weekly "estimation" meeting, why not have a weekly "backlog grooming" meeting where the team also helps the PO prioritize the higher priority items on the existing backlog, as well as estimate new high-priority tasks?

                  Maybe this is what you already do?

                  Best,
                  Alex

                  --- In scrumdevelopment@yahoogroups.com, Robert Molchon <rob.molchon@...> wrote:
                  >
                  > Hello fellow scrum enthusiasts,
                  >
                  > I was wondering what people thought of having the Product Owner attend the Team's product backlog estimation meetings?
                  >
                  > On one hand it can be a good thing, as the Product Owner can help provide color and answer questions regarding the meaning of the backlog items that the team is estimating. This is what we currently do. Each team has a weekly backlog estimation meeting to go through any unestimated items on the backlog and the Product Owner generally attends.
                  >
                  > On the other hand, I have noticed that being in the estimation meeting can lead to less well written backlog items since the PO knows that he or she will be in the meeting to explain it to the team.
                  >
                  > What, dear friends, do you think?
                  >
                  > Thanks
                  > Rob
                  >
                  >
                  > ------------------------------------
                  > Rob Molchon
                  > Vice-President, Engineering
                  >
                  > Unicast
                  > 205 West 39th Street 16th Floor
                  > New York, NY 10018
                  > Office: 212.201.0856
                  > Cell: 917.214.0551
                  > Fax: 212.201.0801
                  > www.unicast.com<http://www.unicast.com/>
                  >
                • Robert Molchon
                  Having weekly estimation meetings are good for a number of reasons. First, you can keep them short and time box them fairly rigidly. If you leave the
                  Message 8 of 18 , Jan 14, 2011
                  • 0 Attachment

                    Having weekly estimation meetings are good for a number of reasons. First, you can keep them short and time box them fairly rigidly. If you leave the estimation right until before the planning the meeting can drag and there is a lot of pressure to estimate everything on the list to be prepared for the selection process.

                     

                    More importantly, having them weekly, gives the team more opportunities to practice the actual action of estimating. The more often we do something, the better we are at it. I would rather have the team get 48 opportunities to hold an estimation meeting than just 12 in a year.

                     

                     Incidentally, I think this why most organizations are not very good at performance reviews. They make them annually therefore managers and employees don’t have a log of practice with the process. It would be much better and probably less work if they held them monthly or quarterly.

                     

                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of alex.armstrong
                    Sent: Thursday, January 13, 2011 9:28 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Re: Having the Product Owner in team Estimation Meetings

                     

                     

                    Rob,

                    You have received some good answers here. I won't reiterate them, but I will add a comment about your statement: "...a weekly backlog estimation meeting to go through any unestimated items on the backlog..."

                    Unless your backlog is only 2 Sprints deep, be sure you aren't wasting team time on needless estimation of PBIs that may never be built. Instead of a weekly "estimation" meeting, why not have a weekly "backlog grooming" meeting where the team also helps the PO prioritize the higher priority items on the existing backlog, as well as estimate new high-priority tasks?

                    Maybe this is what you already do?

                    Best,
                    Alex

                    --- In scrumdevelopment@yahoogroups.com, Robert Molchon <rob.molchon@...> wrote:

                    >
                    > Hello fellow scrum enthusiasts,
                    >
                    > I was wondering what people thought of having the Product Owner attend the
                    Team's product backlog estimation meetings?
                    >
                    > On one hand it can be a good thing, as the Product Owner can help provide
                    color and answer questions regarding the meaning of the backlog items that the team is estimating. This is what we currently do. Each team has a weekly backlog estimation meeting to go through any unestimated items on the backlog and the Product Owner generally attends.
                    >
                    > On the other hand, I have noticed that being in the estimation meeting can
                    lead to less well written backlog items since the PO knows that he or she will be in the meeting to explain it to the team.
                    >
                    > What, dear friends, do you think?
                    >
                    > Thanks
                    > Rob
                    >
                    >
                    > ------------------------------------
                    > Rob Molchon
                    > Vice-President, Engineering
                    >
                    > Unicast
                    > 205 West 39th Street 16th Floor
                    > New York, NY 10018
                    > Office: 212.201.0856
                    > Cell: 917.214.0551
                    > Fax: 212.201.0801
                    > www.unicast.com<http://www.unicast.com/>
                    >

                  • thierry henrio
                    Hello Robert ... What is the goal of estimates ? Does it help to produce valuable software ? Is there customers asking for weekly | monthly estimates ? I
                    Message 9 of 18 , Jan 14, 2011
                    • 0 Attachment
                      Hello Robert
                      On Fri, Jan 14, 2011 at 6:59 PM, Robert Molchon <rob.molchon@...> wrote:
                      Having weekly estimation meetings are good for a number of reasons. First, you can keep them short and time box them fairly rigidly. If you leave the estimation right until before the planning the meeting can drag and there is a lot of pressure to estimate everything on the list to be prepared for the selection process.

                       

                      More importantly, having them weekly, gives the team more opportunities to practice the actual action of estimating.

                      What is the goal of estimates ?
                      Does it help to produce valuable software ?
                      Is there customers asking for weekly | monthly estimates ?

                      I believe measures are better than estimates
                      What would it require for an estimate to be near previous measures ?
                      Curious, Thierry


                    • Dan
                      Hi Rob, I tend to agree with everyone else here. I am a PO and I attend almost every meeting for every team I am involved with. I m there to answer questions
                      Message 10 of 18 , Jan 17, 2011
                      • 0 Attachment
                        Hi Rob, I tend to agree with everyone else here. I am a PO and I attend almost every meeting for every team I am involved with. I'm there to answer questions more than to offer anything on my own.

                        One thing that we may do different here is, I run the Planning Poker meetings. I'll read through the user stories, answer any questions that come up, let the team come up with their estimate, and then I record it.

                        I have my own rule that once the team starts the process of agreeing on story points, I shut up until they are done. I never influence their decisions on this matter since they are the ones that need ot commit to getting it done.

                        Hope this helps,
                        Dan

                        --- In scrumdevelopment@yahoogroups.com, Robert Molchon <rob.molchon@...> wrote:
                        >
                        > I was wondering what people thought of having the Product Owner attend the Team's product backlog estimation meetings?...
                      • JackM
                        Sounds like you got this nailed! Good job. Jack www.agilebuddy.com blog.agilebuddy.com
                        Message 11 of 18 , Jan 19, 2011
                        • 0 Attachment
                          Sounds like you got this nailed!

                          Good job.
                          Jack
                          www.agilebuddy.com
                          blog.agilebuddy.com

                          --- In scrumdevelopment@yahoogroups.com, "Dan" <hd_one50@...> wrote:
                          >
                          > Hi Rob, I tend to agree with everyone else here. I am a PO and I attend almost every meeting for every team I am involved with. I'm there to answer questions more than to offer anything on my own.
                          >
                          > One thing that we may do different here is, I run the Planning Poker meetings. I'll read through the user stories, answer any questions that come up, let the team come up with their estimate, and then I record it.
                          >
                          > I have my own rule that once the team starts the process of agreeing on story points, I shut up until they are done. I never influence their decisions on this matter since they are the ones that need ot commit to getting it done.
                          >
                          > Hope this helps,
                          > Dan
                          >
                          > --- In scrumdevelopment@yahoogroups.com, Robert Molchon <rob.molchon@> wrote:
                          > >
                          > > I was wondering what people thought of having the Product Owner attend the Team's product backlog estimation meetings?...
                          >
                        • langvtran
                          ... areas and ... situation. ... What is the correct role for the PO to play here? I d like to disagree on the view that PO s should not influence the
                          Message 12 of 18 , Jan 20, 2011
                          • 0 Attachment
                            --- In scrumdevelopment@yahoogroups.com, "Charles Bradley - Scrum Coach, CSM, PSM I" <chuck-lists2@...> wrote:
                            >
                            > > Incidentally I am of the opinion that more participation in all areas and
                            > >aspects of Scrum by the product owner is a good thing!
                            >
                            > ++1, so long as the PO only plays the (correct) PO role in that situation.
                            >
                            > cb

                            What is the correct role for the PO to play here?

                            I'd like to disagree on the view that PO's should not influence the estimates of the team. I believe the PO does and should influence the estimates of the team. The goal is to ensure that minimal marketable feature are being delivered first. She can do this by listening to her team and then fine tuning the acceptance criteria. Another example is when an estimate seems "off", she should ask why. It could be the team was thinking of building something more complex than she needs. Or there could a very valid reason that she didn't realize before.

                            This should be in a team context and not command-and-control. The PO does not get final say on estimates but should be allowed her input. If the PO can convince the team to decrease their estimate, so be it. If the team cannot complete the story that sprint because it was bigger than expected, it would be a good topic for the retrospective.

                            Lang
                          • Ron Jeffries
                            Hello, langvtran. On Thursday, January 20, 2011, at 8:01:58 AM, ... In the scenario you describe, I would not say that the PO is influencing estimates. She is
                            Message 13 of 18 , Jan 20, 2011
                            • 0 Attachment
                              Hello, langvtran. On Thursday, January 20, 2011, at 8:01:58 AM,
                              you wrote:

                              > What is the correct role for the PO to play here?
                              > I'd like to disagree on the view that PO's should not influence the
                              > estimates of the team. I believe the PO does and should influence the
                              > estimates of the team. The goal is to ensure that minimal marketable
                              > feature are being delivered first. She can do this by listening to her
                              > team and then fine tuning the acceptance criteria. Another example is
                              > when an estimate seems "off", she should ask why. It could be the team
                              > was thinking of building something more complex than she needs. Or there
                              > could a very valid reason that she didn't realize before.
                              > This should be in a team context and not command-and-control. The PO
                              > does not get final say on estimates but should be allowed her input. If
                              > the PO can convince the team to decrease their estimate, so be it. If
                              > the team cannot complete the story that sprint because it was bigger
                              > than expected, it would be a good topic for the retrospective.

                              In the scenario you describe, I would not say that the PO is
                              influencing estimates. She is using estimates to change what she
                              asks for, to make what she asks for smaller.

                              She's not saying "do that faster or cheaper". She's saying "oh,
                              that's expensive, how about if we did this instead?"

                              See what I mean?

                              Ron Jeffries
                              www.XProgramming.com
                              Speed is ppoor subsittute fo accurancy. -- Fortune Cookie
                            • daswartz@prodigy
                              Hello Ron, ... And that is a VERY good thing... And one of the best reasons to have the Product Owner in the meeting. -- Doug Swartz
                              Message 14 of 18 , Jan 20, 2011
                              • 0 Attachment
                                Hello Ron,

                                Thursday, January 20, 2011, 7:18:32 AM, you wrote:

                                > Hello, langvtran. On Thursday, January 20, 2011, at 8:01:58 AM,
                                > you wrote:

                                >> What is the correct role for the PO to play here?
                                >> I'd like to disagree on the view that PO's should not influence the
                                >> estimates of the team. I believe the PO does and should influence the
                                >> estimates of the team. The goal is to ensure that minimal marketable
                                >> feature are being delivered first. She can do this by listening to her
                                >> team and then fine tuning the acceptance criteria. Another example is
                                >> when an estimate seems "off", she should ask why. It could be the team
                                >> was thinking of building something more complex than she needs. Or there
                                >> could a very valid reason that she didn't realize before.
                                >> This should be in a team context and not command-and-control. The PO
                                >> does not get final say on estimates but should be allowed her input. If
                                >> the PO can convince the team to decrease their estimate, so be it. If
                                >> the team cannot complete the story that sprint because it was bigger
                                >> than expected, it would be a good topic for the retrospective.

                                > In the scenario you describe, I would not say that the PO is
                                > influencing estimates. She is using estimates to change what she
                                > asks for, to make what she asks for smaller.

                                > She's not saying "do that faster or cheaper". She's saying "oh,
                                > that's expensive, how about if we did this instead?"

                                And that is a VERY good thing... And one of the best reasons to have
                                the Product Owner in the meeting.

                                --
                                Doug Swartz
                              • langvtran
                                ... the ... marketable ... her ... is ... team ... there ... I actually meant the them as two separate scenarios, sorry if that wasn t clear. In the first
                                Message 15 of 18 , Jan 20, 2011
                                • 0 Attachment
                                  --- In scrumdevelopment@yahoogroups.com, "daswartz@..." <daswartz@...> wrote:
                                  >
                                  > Hello Ron,
                                  >
                                  > Thursday, January 20, 2011, 7:18:32 AM, you wrote:
                                  >
                                  > > Hello, langvtran. On Thursday, January 20, 2011, at 8:01:58 AM,
                                  > > you wrote:
                                  >
                                  > >> What is the correct role for the PO to play here?
                                  > >> I'd like to disagree on the view that PO's should not influence the
                                  > >> estimates of the team. I believe the PO does and should influence the
                                  > >> estimates of the team. The goal is to ensure that minimal marketable
                                  > >> feature are being delivered first. She can do this by listening to her
                                  > >> team and then fine tuning the acceptance criteria. Another example is
                                  > >> when an estimate seems "off", she should ask why. It could be the team
                                  > >> was thinking of building something more complex than she needs. Or there
                                  > >> could a very valid reason that she didn't realize before.

                                  > > In the scenario you describe, I would not say that the PO is
                                  > > influencing estimates. She is using estimates to change what she
                                  > > asks for, to make what she asks for smaller.
                                  >
                                  > > She's not saying "do that faster or cheaper". She's saying "oh,
                                  > > that's expensive, how about if we did this instead?"
                                  >
                                  > And that is a VERY good thing... And one of the best reasons to have
                                  > the Product Owner in the meeting.

                                  I actually meant the them as two separate scenarios, sorry if that wasn't clear. In the first scenario, it's definitely true she was using the estimates to adjust the ask. My second scenario is a case where the PO and team didn't reach the same understanding of a story and only realized this after the estimates were given. Another scenario could be the PO thinks the team underestimated and realized she didn't cover all the wanted functionality. Morale of the story, PO should be at the meeting.

                                  Lang
                                • alex.armstrong
                                  Lang, Ron is absolutely correct. Your last two scenarios are similar examples of the PO using an estimate to validate understanding, not influence the
                                  Message 16 of 18 , Jan 20, 2011
                                  • 0 Attachment
                                    Lang,

                                    Ron is absolutely correct. Your last two scenarios are similar examples of the PO using an estimate to validate understanding, not influence the estimate. It may seem like splitting hairs, but it is an important distinction.

                                    The PO is making sure there is a common understanding of the story, and increasing or decreasing the scope accordingly based on the estimation. The estimate for the work needed is up to the people delivering the increment.

                                    Best,
                                    Alex

                                    --- In scrumdevelopment@yahoogroups.com, "langvtran" <langvtran@...> wrote:
                                    >
                                    >
                                    > --- In scrumdevelopment@yahoogroups.com, "daswartz@" <daswartz@>
                                    > wrote:
                                    > >
                                    > > Hello Ron,
                                    > >
                                    > > Thursday, January 20, 2011, 7:18:32 AM, you wrote:
                                    > >
                                    > > > Hello, langvtran. On Thursday, January 20, 2011, at 8:01:58 AM,
                                    > > > you wrote:
                                    > >
                                    > > >> What is the correct role for the PO to play here?
                                    > > >> I'd like to disagree on the view that PO's should not influence the
                                    > > >> estimates of the team. I believe the PO does and should influence
                                    > the
                                    > > >> estimates of the team. The goal is to ensure that minimal
                                    > marketable
                                    > > >> feature are being delivered first. She can do this by listening to
                                    > her
                                    > > >> team and then fine tuning the acceptance criteria. Another example
                                    > is
                                    > > >> when an estimate seems "off", she should ask why. It could be the
                                    > team
                                    > > >> was thinking of building something more complex than she needs. Or
                                    > there
                                    > > >> could a very valid reason that she didn't realize before.
                                    >
                                    > > > In the scenario you describe, I would not say that the PO is
                                    > > > influencing estimates. She is using estimates to change what she
                                    > > > asks for, to make what she asks for smaller.
                                    > >
                                    > > > She's not saying "do that faster or cheaper". She's saying "oh,
                                    > > > that's expensive, how about if we did this instead?"
                                    > >
                                    > > And that is a VERY good thing... And one of the best reasons to have
                                    > > the Product Owner in the meeting.
                                    >
                                    > I actually meant the them as two separate scenarios, sorry if that
                                    > wasn't clear. In the first scenario, it's definitely true she was using
                                    > the estimates to adjust the ask. My second scenario is a case where the
                                    > PO and team didn't reach the same understanding of a story and only
                                    > realized this after the estimates were given. Another scenario could be
                                    > the PO thinks the team underestimated and realized she didn't cover all
                                    > the wanted functionality. Morale of the story, PO should be at the
                                    > meeting.
                                    > Lang
                                    >
                                  • langvtran
                                    ... examples of the PO using an estimate to validate understanding, not influence the estimate. It may seem like splitting hairs, but it is an important
                                    Message 17 of 18 , Jan 21, 2011
                                    • 0 Attachment
                                      --- In scrumdevelopment@yahoogroups.com, "alex.armstrong" <alex.armstrong@...> wrote:
                                      > Ron is absolutely correct. Your last two scenarios are similar examples of the PO using an estimate to validate understanding, not influence the estimate. It may seem like splitting hairs, but it is an important distinction.
                                      >
                                      > The PO is making sure there is a common understanding of the story, and increasing or decreasing the scope accordingly based on the estimation. The estimate for the work needed is up to the people delivering the increment.

                                      I'm in full agreement here.

                                      Lang
                                    • scrumnoob
                                      These two comments nail it for me (summarising below replies). Estimates can be lowered on request, but it wont change how long the work takes. Retrospective
                                      Message 18 of 18 , Feb 2, 2011
                                      • 0 Attachment
                                        These two comments nail it for me (summarising below replies).

                                        Estimates can be lowered on request, but it wont change how long the work takes. Retrospective should address this behaviour.

                                        Estimates can be lowered through the trading of feature richness, this trading can start when story estimates are initially floated and the rationale explained. Prefer this over former.




                                        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                        >
                                        > Hello, langvtran. On Thursday, January 20, 2011, at 8:01:58 AM,
                                        > you wrote:
                                        >
                                        > > What is the correct role for the PO to play here?
                                        > > I'd like to disagree on the view that PO's should not influence the
                                        > > estimates of the team. I believe the PO does and should influence the
                                        > > estimates of the team. The goal is to ensure that minimal marketable
                                        > > feature are being delivered first. She can do this by listening to her
                                        > > team and then fine tuning the acceptance criteria. Another example is
                                        > > when an estimate seems "off", she should ask why. It could be the team
                                        > > was thinking of building something more complex than she needs. Or there
                                        > > could a very valid reason that she didn't realize before.
                                        > > This should be in a team context and not command-and-control. The PO
                                        > > does not get final say on estimates but should be allowed her input. If
                                        > > the PO can convince the team to decrease their estimate, so be it. If
                                        > > the team cannot complete the story that sprint because it was bigger
                                        > > than expected, it would be a good topic for the retrospective.
                                        >
                                        > In the scenario you describe, I would not say that the PO is
                                        > influencing estimates. She is using estimates to change what she
                                        > asks for, to make what she asks for smaller.
                                        >
                                        > She's not saying "do that faster or cheaper". She's saying "oh,
                                        > that's expensive, how about if we did this instead?"
                                        >
                                        > See what I mean?
                                        >
                                        > Ron Jeffries
                                        > www.XProgramming.com
                                        > Speed is ppoor subsittute fo accurancy. -- Fortune Cookie
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.