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

Re: Who owns technical features in the product backlog?

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