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

Re: [scrumdevelopment] Re: Who owns technical features in the product backlog?

Expand Messages
  • Rob Park
    I would 2nd this. And also, why can the team not deliver what they have today? .rob.
    Message 1 of 18 , Jun 1, 2008
    • 0 Attachment
      I would 2nd this.
       
      And also, why can the team not deliver what they have today?
       
      .rob.

      On Fri, May 30, 2008 at 5:47 AM, m.sumrell <m.sumrell@...> wrote:

      Paul -
      My advice is to have the team write ALL stories in a way that shows
      benefit to the customer. The customer should be able to understand
      all the stories in the backlog. Mike Cohn's book on User Stories
      gives some great examples on how to do this.

      --- In scrumdevelopment@yahoogroups.com, "beckfordp" <beckfordp@...>
      wrote:


      >
      > Hi All,
      >
      > I have recently started working as a coach with a team that has
      > primarily been using Scrum. They have an established backlog which
      > includes a number of technical features. I believe that this is
      > ligitimate in Scrum. The problem we are having is getting firm
      > ownership of the backlog. From the customers point of view, the
      > backlog is a "to do list" for the development team. If I say that
      the
      > team have been going for 18 months and is planning on delivering
      it's
      > first release in the next two months then you'll get the picture :)
      >
      > So the customer doesn't feel that he owns the backlog. He is just
      > waiting for his realse, waterfall style. This feeling is reinforced
      by
      > technical features in the backlog that are created by the lead
      > architect, and assigned priority based on his advice, and which
      > clearly do not belong to the customer.
      >
      > How does this work in a Scrum team.? My experience is XP.
      >
      > Regards,
      >
      > Paul.
      >


    • Petri Heiramo
      Hi Paul, Sounds to me the problem isn t in the PO or in the technical stories. I mean, sure, those areas may need improvement, but they are not the core
      Message 2 of 18 , Jun 2, 2008
      • 0 Attachment
        Hi Paul,


        Sounds to me the problem isn't in the PO or in the technical stories.
        I mean, sure, those areas may need improvement, but they are not the
        core problem. I think you addressed the core problem yourself: not
        releasing things.

        If you don't release, you don't do workable iterative and incremental
        software development. You don't get feedback, you don't get customer
        ownership, you don't get tested working milestones. I don't know if
        the team releases "potentially shippable increments of functionality",
        but if they don't you don't have incremental development, either. It's
        just waterfall with a different management framework, with pretty much
        all the problems of waterfall development.

        So the first thing I would do is check how the team's operation fits
        in with the goals of iterative and incremental development & the
        values and principles of Agile development. Then coach the team to
        change they work to match them. Only _then_ I think it makes sense to
        go to coach the PO (as you stated yourself).

        The typical problem with technical stories is that they tend to be
        horizontal. That is, they don't address end user functionality
        directly. It is difficult to do effective iterative and incremental
        development when you can only deliver partial functionality at a time.
        So if you see that kind of problems in the product backlog, it would
        make sense to rework those issues with the team.

        Now, if the lead architect is used to running the show, you might have
        problems turning the ship about. He is the person you need to
        convince. He is either your best friend or your strongest opponent.
        The PO seems detached and sounds unlikely to impose requirements on
        the project. He already doesn't demand milestones, so why would he
        oppose improvements to his position? [I don't mean that the milestones
        would be good to require, but it just shows he doesn't require
        specific issues even if he thinks they would be good in his opinion.]


        Wishing you good luck,


        Petri Heiramo
        Senior Process Improvement Manager, CSP
        Digia Plc., Finland

        > Hi All,
        >
        > I have recently started working as a coach with a team that has
        > primarily been using Scrum. They have an established backlog which
        > includes a number of technical features. I believe that this is
        > ligitimate in Scrum. The problem we are having is getting firm
        > ownership of the backlog. From the customers point of view, the
        > backlog is a "to do list" for the development team. If I say that the
        > team have been going for 18 months and is planning on delivering it's
        > first release in the next two months then you'll get the picture :)
        >
        > So the customer doesn't feel that he owns the backlog. He is just
        > waiting for his realse, waterfall style. This feeling is reinforced by
        > technical features in the backlog that are created by the lead
        > architect, and assigned priority based on his advice, and which
        > clearly do not belong to the customer.
        >
        > How does this work in a Scrum team.? My experience is XP.
        >
        > Regards,
        >
        > Paul.
      • beckfordp
        ... Yep - Which is why I have been treading gently :) Despite this the organisation has chosen Scrum as the way forward and the PO needs to be aware of his
        Message 3 of 18 , Jun 2, 2008
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, "barvybe" <pgoldey@...> wrote:
          >
          > I think the real issue here is around the release timeframes you
          > mentioned.
          >
          > The "team" should be demonstrating code every few weeks that the
          > customer reviews and provides feedback on. The customer can then
          > "release" the product as soon / late as they wish, do multiple
          > releases, etc.
          >
          > Otherwise, you are correct - from the customer's perspective this is
          > waterfall and hence the tensions you are dealing with.
          >
          > Pete
          >
          Yep - Which is why I have been treading gently :)

          Despite this the organisation has chosen Scrum as the way forward and
          the PO needs to be aware of his responsibilities.

          I'll be speaking to the PO today. Wish me luck :)

          Paul.
        • beckfordp
          ... Yep - I intend to run through a story re-write with the PO first so that he can see the value in it. Thanx, P.
          Message 4 of 18 , Jun 2, 2008
          • 0 Attachment
            --- In scrumdevelopment@yahoogroups.com, "m.sumrell" <m.sumrell@...>
            wrote:
            >
            > Paul -
            > My advice is to have the team write ALL stories in a way that shows
            > benefit to the customer. The customer should be able to understand
            > all the stories in the backlog. Mike Cohn's book on User Stories
            > gives some great examples on how to do this.
            >
            >
            > --- In scrumdevelopment@yahoogroups.com, "beckfordp" <beckfordp@>
            > wrote:
            > >
            > > Hi All,
            > >
            > > I have recently started working as a coach with a team that has
            > > primarily been using Scrum. They have an established backlog which
            > > includes a number of technical features. I believe that this is
            > > ligitimate in Scrum. The problem we are having is getting firm
            > > ownership of the backlog. From the customers point of view, the
            > > backlog is a "to do list" for the development team. If I say that
            > the
            > > team have been going for 18 months and is planning on delivering
            > it's
            > > first release in the next two months then you'll get the picture :)
            > >
            > > So the customer doesn't feel that he owns the backlog. He is just
            > > waiting for his realse, waterfall style. This feeling is reinforced
            > by
            > > technical features in the backlog that are created by the lead
            > > architect, and assigned priority based on his advice, and which
            > > clearly do not belong to the customer.
            > >
            > > How does this work in a Scrum team.? My experience is XP.
            > >
            > > Regards,
            > >
            > > Paul.
            > >
            >
            Yep - I intend to run through a story re-write with the PO first so
            that he can see the value in it.

            Thanx,

            P.
          • beckfordp
            Hi Petri, Your reading of the situation is spot on. There are a number of complex people issues at play. I ve been here before, so I ll be applying my usual
            Message 5 of 18 , Jun 2, 2008
            • 0 Attachment
              Hi Petri,

              Your reading of the situation is spot on. There are a number of
              complex people issues at play.

              I've been here before, so I'll be applying my usual charms in an
              attempt to influence the team in a positive direction.

              Thanks for the advice.

              Paul.

              --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo"
              <petri.heiramo@...> wrote:
              >
              > Hi Paul,
              >
              >
              > Sounds to me the problem isn't in the PO or in the technical stories.
              > I mean, sure, those areas may need improvement, but they are not the
              > core problem. I think you addressed the core problem yourself: not
              > releasing things.
              >
              > If you don't release, you don't do workable iterative and incremental
              > software development. You don't get feedback, you don't get customer
              > ownership, you don't get tested working milestones. I don't know if
              > the team releases "potentially shippable increments of functionality",
              > but if they don't you don't have incremental development, either. It's
              > just waterfall with a different management framework, with pretty much
              > all the problems of waterfall development.
              >
              > So the first thing I would do is check how the team's operation fits
              > in with the goals of iterative and incremental development & the
              > values and principles of Agile development. Then coach the team to
              > change they work to match them. Only _then_ I think it makes sense to
              > go to coach the PO (as you stated yourself).
              >
              > The typical problem with technical stories is that they tend to be
              > horizontal. That is, they don't address end user functionality
              > directly. It is difficult to do effective iterative and incremental
              > development when you can only deliver partial functionality at a time.
              > So if you see that kind of problems in the product backlog, it would
              > make sense to rework those issues with the team.
              >
              > Now, if the lead architect is used to running the show, you might have
              > problems turning the ship about. He is the person you need to
              > convince. He is either your best friend or your strongest opponent.
              > The PO seems detached and sounds unlikely to impose requirements on
              > the project. He already doesn't demand milestones, so why would he
              > oppose improvements to his position? [I don't mean that the milestones
              > would be good to require, but it just shows he doesn't require
              > specific issues even if he thinks they would be good in his opinion.]
              >
              >
              > Wishing you good luck,
              >
              >
              > Petri Heiramo
              > Senior Process Improvement Manager, CSP
              > Digia Plc., Finland
              >
              > > Hi All,
              > >
              > > I have recently started working as a coach with a team that has
              > > primarily been using Scrum. They have an established backlog which
              > > includes a number of technical features. I believe that this is
              > > ligitimate in Scrum. The problem we are having is getting firm
              > > ownership of the backlog. From the customers point of view, the
              > > backlog is a "to do list" for the development team. If I say that the
              > > team have been going for 18 months and is planning on delivering it's
              > > first release in the next two months then you'll get the picture :)
              > >
              > > So the customer doesn't feel that he owns the backlog. He is just
              > > waiting for his realse, waterfall style. This feeling is reinforced by
              > > technical features in the backlog that are created by the lead
              > > architect, and assigned priority based on his advice, and which
              > > clearly do not belong to the customer.
              > >
              > > How does this work in a Scrum team.? My experience is XP.
              > >
              > > Regards,
              > >
              > > Paul.
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.