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

Re: Who owns technical features in the product backlog?

Expand Messages
  • 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 1 of 18 , Jun 2, 2008
      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 2 of 18 , Jun 2, 2008
        --- 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 3 of 18 , Jun 2, 2008
          --- 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 4 of 18 , Jun 2, 2008
            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.