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

Re: Who owns technical features in the product backlog?

Expand Messages
  • 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 1 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 2 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.