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.
--- In email@example.com
, Keith Lancaster
> 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?
> Yahoo! Mail Mobile
> Take Yahoo! Mail with you! Check email on your mobile phone.