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

Re: Basic question (I think): Product Owner role during sprint

Expand Messages
  • Simon Baker
    I like the PO to be the equivalent of extreme programming s onsite customer, becoming an integral part of the team and ideally colocated. The PO takes a very
    Message 1 of 2 , Jun 29, 2005
    • 0 Attachment
      I like the PO to be the equivalent of extreme programming's onsite
      customer, becoming an integral part of the team and ideally colocated.

      The PO takes a very active part in the first half of the scrum
      planning meeting where, in simple terms, the content of the sprint is
      being negotiated and the sprint goal defined. (The second part of the
      sprint involves the techies disaggregating reqs - i use user stories -
      into engineering tasks and providing estimates). Similarly, the PO is
      active during the sprint review. And if a proactive member of the
      team, the PO should also be involved in the retrospective.

      I would expect the PO to have duties beyond the sprint. E.g. they may
      just be the business representative on the team and are therefore the
      interface into the business. This means they interact with business
      people when gathering and eliciting product backlog items.

      While the sprint is occuring they should be managing the product
      backlog and constantly assessing the priorities of items on the
      product backlog in reaction to changing circumstances and
      requirements. These activities effectively lay out an evolving roadmap
      for sprints ahead of the current sprint, which is obviously useful to
      the business. Of course, future sprints are never exactly nailed until
      they become the current sprint and planning commences forthat sprint.

      They also need to be available to answer questions, elaborate on
      required functionality and behaviour and to provide feedback to the
      developers. This is critical when employing user stories to represent
      desired functionality because what is really required only emerges
      through conversation. Feedback, e.g. viewing the acceptance tests
      passing so far, or playing with an increment of UI is valuable because
      the comments can steer the development effort ... "I don't like that
      button there, blah blah".

      What's important is that, if the PO has other responsibilities beyond
      the team, they do not prevent the PO from fulfilling the above duties
      to the team and to the sprint. The PO is equally responsible for the
      success of the project as the team, and therefore needs to be
      dedicated, proactive and available.

      In my experience, when POs fail to engage throughout the sprint and
      only participate during planning are bad. This situation demonstrates
      that they do not understand the mechanism of Scrum, their role and
      responsibility, and how their contributionis important to success.
      Typically they retain the notion of throwing the project over the wall
      to the techies - this is a comfort zone for them - "it's the techies
      responsibility to deliver and if they don't i'm automatically
      exonerated because they're to blame".

      In reality, the PO probably has other duties to fulfill beyond the
      team and therefore some compromise must be reached between the techies
      and the PO in terms of providing an acceptable level of service and
      engagement during the sprint. The scrum master should facilitate the
      involvement of the PO.

      Simon Baker




      --- In scrumdevelopment@yahoogroups.com, Keith Lancaster
      <klancaster1957@y...> wrote:
      > All,
      > I've read a good deal of the posts on this group, and
      > both available books on Scrum, and am still a bit
      > confused on the role of the PO *during* the sprint.
      > Making the assumption for now that the PO is in fact a
      > single person, what is his/her expected day like
      > during the course of a sprint? Is the expectation that
      > the PO is in the dev team room throughout the day,
      > helping to clarify requirements? Or is it the
      > opposite, where the involvement is basically during
      > the sprint planning sessions and limited during the
      > actual sprint? Somewhere in between? Any pros/cons
      > folks have seen from either approach?
      >
      > TIA,
      > Keith
      >
      >
      >
      > __________________________________
      > Yahoo! Mail Mobile
      > Take Yahoo! Mail with you! Check email on your mobile phone.
      > http://mobile.yahoo.com/learn/mail
    Your message has been successfully submitted and would be delivered to recipients shortly.