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

Re: Product Backlog is "Dynamic"

Expand Messages
  • woynam
    I m not following you. The PO manages the product backlog. If the PO adds something to the backlog, then by definition it is not scope creep. In fact, with
    Message 1 of 13 , Jan 30, 2009
    • 0 Attachment
      I'm not following you. The PO manages the product backlog. If the PO
      adds something to the backlog, then by definition it is not scope
      creep. In fact, with Scrum, I don't believe there is *ever* scope
      creep. Scope doesn't really exist until it's accepted by the team and
      it gets worked on in an iteration.

      In a nutshell, everything in the backlog that isn't being worked on is
      simply the PO's wish list. Since it's possible that an item in the
      backlog may *never* get worked on, it's not really part of the scope
      in the traditional sense.

      Mark

      --- In scrumdevelopment@yahoogroups.com, Pablo Emanuel
      <pablo.emanuel@...> wrote:
      >
      > Ravi,
      >
      > the answer is that if it's correctly managed it's just scope change,
      > otherwise it's scope creep. Scope creep occurs when new scope finds
      a way to
      > sneak into the project without the correct decision-makers being
      aware of
      > it, and of its impact on the project. So, if your product backlog (which
      > indeed has to be dynamic, because that's one of the pillars of the
      > agile/iterative approach) is constantly validated by the correct
      people (in
      > Scrum, the PO is the one that is responsible for making it happen),
      you can
      > avoid the scope creep. Having said that, Scrum is not immune to
      Scope Creep,
      > all depends on the PO doing his job right.
      >
      > Regards,
      > Pablo Emanuel
      >
      > 2009/1/30 Ravichandra Reddy Gunturu <ravigunturu@...>
      >
      > > says page 10 of Ken Schwaber's book "Agile PM with Scrum"
      > >
      > > So how do we distinguish between a "dynamic" backlog and our old
      > > nemesis, SCOPE CREEP.
      > >
      > > Ravi
      > >
      > >
      > >
      >
    • Ravichandra Gunturu
      THANK YOU. That IS my point. If there is no scope, it is going to be a free for all. My clients are the proverbial noses of a camel... But, point taken. Being
      Message 2 of 13 , Jan 30, 2009
      • 0 Attachment
        THANK YOU. That IS my point. If there is no scope, it is going to be a free for all.
         
        My clients are the proverbial noses of a camel...
         
        But, point taken. Being a freshly minted PMP, I am trying to reconcile both philosophies in my head.


        From: woynam <woyna@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Friday, January 30, 2009 11:48:13 AM
        Subject: [scrumdevelopment] Re: Product Backlog is "Dynamic"


        I'm not following you. The PO manages the product backlog. If the PO
        adds something to the backlog, then by definition it is not scope
        creep. In fact, with Scrum, I don't believe there is *ever* scope
        creep. Scope doesn't really exist until it's accepted by the team and
        it gets worked on in an iteration.

        In a nutshell, everything in the backlog that isn't being worked on is
        simply the PO's wish list. Since it's possible that an item in the
        backlog may *never* get worked on, it's not really part of the scope
        in the traditional sense.

        Mark

        --- In scrumdevelopment@ yahoogroups. com, Pablo Emanuel
        <pablo.emanuel@ ...> wrote:

        >
        > Ravi,
        >
        > the answer is that if it's correctly managed it's just scope change,
        > otherwise it's scope creep.
        Scope creep occurs when new scope finds
        a way to
        > sneak into the project without the correct decision-makers being
        aware of
        > it, and of its impact on the project. So, if your product backlog (which
        > indeed has to be dynamic, because that's one of the pillars of the
        > agile/iterative approach) is constantly validated by the correct
        people (in
        > Scrum, the PO is the one that is responsible for making it happen),
        you can
        > avoid the scope creep. Having said that, Scrum is not immune to
        Scope Creep,
        > all depends on the PO doing his job right.
        >
        > Regards,
        > Pablo Emanuel
        >
        > 2009/1/30 Ravichandra Reddy Gunturu <ravigunturu@ ...>
        >
        > > says page 10 of Ken Schwaber's book "Agile PM with Scrum"
        > >
        > > So how do we distinguish between a "dynamic" backlog and our old
        > > nemesis, SCOPE CREEP.
        > >
        > >
        Ravi
        > >
        > >
        > >
        >

      • Paul Hudson
        It s not no scope . It s managed scope, adjusted every iteration/sprint. Putting hard boundaries around some defined scope just takes you back to change
        Message 3 of 13 , Jan 30, 2009
        • 0 Attachment

          It’s not “no scope”. It’s managed scope, adjusted every iteration/sprint.

           

          Putting hard boundaries around some defined scope just takes you back to change request hell….

           

        • Pablo Emanuel
          Mark, that s exactly what I consider the single greatest risk of Scrum. From Scrum s point of view, the PO is the omnipotent and omniscient being that has all
          Message 4 of 13 , Jan 30, 2009
          • 0 Attachment
            Mark,
             
            that's exactly what I consider the single greatest risk of Scrum. From Scrum's point of view, the PO is the omnipotent and omniscient being that has all the business knowledge and power to understand what needs to be done, in which priority. Of course, that's seldom the case in real life, so the real scope management complexity is entirely on the PO's shoulder. He/she needs to involve all the other stakeholders that live outside the Scrum's boundaries and represent their interests. In "traditional" project management, that's one of the roles of the PM, and it's explicit. In Scrum, it sometimes is so implicitly assumed, that many people can't see that it exists (as proven by your message).
             
            Regards,
            Pablo Emanuel

            2009/1/30 woynam <woyna@...>


            I'm not following you. The PO manages the product backlog. If the PO
            adds something to the backlog, then by definition it is not scope
            creep. In fact, with Scrum, I don't believe there is *ever* scope
            creep. Scope doesn't really exist until it's accepted by the team and
            it gets worked on in an iteration.

            In a nutshell, everything in the backlog that isn't being worked on is
            simply the PO's wish list. Since it's possible that an item in the
            backlog may *never* get worked on, it's not really part of the scope
            in the traditional sense.

            Mark

            --- In scrumdevelopment@yahoogroups.com, Pablo Emanuel


            <pablo.emanuel@...> wrote:
            >
            > Ravi,
            >
            > the answer is that if it's correctly managed it's just scope change,
            > otherwise it's scope creep. Scope creep occurs when new scope finds
            a way to
            > sneak into the project without the correct decision-makers being
            aware of
            > it, and of its impact on the project. So, if your product backlog (which
            > indeed has to be dynamic, because that's one of the pillars of the
            > agile/iterative approach) is constantly validated by the correct
            people (in
            > Scrum, the PO is the one that is responsible for making it happen),
            you can
            > avoid the scope creep. Having said that, Scrum is not immune to
            Scope Creep,
            > all depends on the PO doing his job right.
            >
            > Regards,
            > Pablo Emanuel
            >
            > 2009/1/30 Ravichandra Reddy Gunturu <ravigunturu@...>

            >
            > > says page 10 of Ken Schwaber's book "Agile PM with Scrum"
            > >
            > > So how do we distinguish between a "dynamic" backlog and our old
            > > nemesis, SCOPE CREEP.
            > >
            > > Ravi
            > >
            > >
            > >
            >


          • woynam
            If the scope was fixed, you probably wouldn t be using Scrum. You d simply create a nice Gantt chart and start from there. The reason we use Scrum on complex
            Message 5 of 13 , Jan 30, 2009
            • 0 Attachment
              If the scope was fixed, you probably wouldn't be using Scrum. You'd
              simply create a nice Gantt chart and start from there.

              The reason we use Scrum on complex projects is that we *know* the
              scope is not understood, and that it's going to change for a number of
              reasons, e.g. clarification, changing business climate.

              Since we don't invest a lot in upfront planning and design, we don't
              lose sleep over the fact that changes happen. In fact, we use it as a
              competitive advantage.

              I once saw a late night informercial targeted towards salesmen. I
              learned that you never directly answer a customer's question. If the
              customer asks, "Does it come in blue?", you answer "Would you like it
              in blue?" By engaging the user, you discover what they really need,
              not what they think they want. By delivering working software
              frequently, we get to the *real* requirements, even if they're
              radically different from the initial vision.

              Mark

              --- In scrumdevelopment@yahoogroups.com, Ravichandra Gunturu
              <ravigunturu@...> wrote:
              >
              > THANK YOU. That IS my point. If there is no scope, it is going to be
              a free for all.
              >
              > My clients are the proverbial noses of a camel...
              >
              > But, point taken. Being a freshly minted PMP, I am trying to
              reconcile both philosophies in my head.
              >
              >
              >
              >
              > ________________________________
              > From: woynam <woyna@...>
              > To: scrumdevelopment@yahoogroups.com
              > Sent: Friday, January 30, 2009 11:48:13 AM
              > Subject: [scrumdevelopment] Re: Product Backlog is "Dynamic"
              >
              >
              >
              > I'm not following you. The PO manages the product backlog. If the PO
              > adds something to the backlog, then by definition it is not scope
              > creep. In fact, with Scrum, I don't believe there is *ever* scope
              > creep. Scope doesn't really exist until it's accepted by the team and
              > it gets worked on in an iteration.
              >
              > In a nutshell, everything in the backlog that isn't being worked on is
              > simply the PO's wish list. Since it's possible that an item in the
              > backlog may *never* get worked on, it's not really part of the scope
              > in the traditional sense.
              >
              > Mark
              >
              > --- In scrumdevelopment@ yahoogroups. com, Pablo Emanuel
              > <pablo.emanuel@ ...> wrote:
              > >
              > > Ravi,
              > >
              > > the answer is that if it's correctly managed it's just scope change,
              > > otherwise it's scope creep. Scope creep occurs when new scope finds
              > a way to
              > > sneak into the project without the correct decision-makers being
              > aware of
              > > it, and of its impact on the project. So, if your product backlog
              (which
              > > indeed has to be dynamic, because that's one of the pillars of the
              > > agile/iterative approach) is constantly validated by the correct
              > people (in
              > > Scrum, the PO is the one that is responsible for making it happen),
              > you can
              > > avoid the scope creep. Having said that, Scrum is not immune to
              > Scope Creep,
              > > all depends on the PO doing his job right.
              > >
              > > Regards,
              > > Pablo Emanuel
              > >
              > > 2009/1/30 Ravichandra Reddy Gunturu <ravigunturu@ ...>
              > >
              > > > says page 10 of Ken Schwaber's book "Agile PM with Scrum"
              > > >
              > > > So how do we distinguish between a "dynamic" backlog and our old
              > > > nemesis, SCOPE CREEP.
              > > >
              > > > Ravi
              > > >
              > > >
              > > >
              > >
              >
            • George Dinwiddie
              ... Um, Ravichandra, I ve got a hunch. Do you have /different/ people responsible for the backlog and for the budget? In other words, is the Product Owner
              Message 6 of 13 , Jan 30, 2009
              • 0 Attachment
                Ravichandra Gunturu wrote:
                > THANK YOU. That IS my point. If there is no scope, it is going to be a
                > free for all.
                >
                > My clients are the proverbial noses of a camel...
                >
                > But, point taken. Being a freshly minted PMP, I am trying to reconcile
                > both philosophies in my head.

                Um, Ravichandra, I've got a hunch. Do you have /different/ people
                responsible for the backlog and for the budget? In other words, is the
                Product Owner who is managing the Product Backlog not on the hook for
                the cost (money and/or time) of producing the Product?

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              Your message has been successfully submitted and would be delivered to recipients shortly.