50491Re: [scrumdevelopment] Who is the Product Owner?
- Mar 5, 2011Peter,
I think you're really referring to "acceptance" more than "done" -- see my other post just a few minutes ago regarding that.
> Acceptance is not something one can really outsource, because youare the only person who can decide whether you have gotten what you wanted for your money.
I agree with you in principle, but, in Scrum, if someone has been chosen to be the PO, whether they come from the customer side or the dev side, that PO does decide PBI/Story acceptance.
So maybe what I'm saying is that, in Scrum, "PO Acceptance" must be decided by the PO.
"Customer Acceptance" (where this is defined to be something like "acceptance by the most powerful business stakeholder") is a different matter altogether. In some ways, I agree with you that PO Acceptance doesn't equal Customer Acceptance. In other ways, I disagree that you can't outsource "Customer Acceptance." You can absolutely do this, it's just that your mileage may vary widely.
In Scrum, I think it's really important that a Scrum team keeps their "eye on the ball" when it comes to PO Acceptance, and this is why I always recommend that the PO Acceptance be obtained as soon as a story is complete, and that the PO *lead* the Sprint Review. The Sprint Review is generally where you find out, among other things, what the difference is between PO Acceptance and Customer Acceptance, which is why the Sprint Review is so important. If you get into a situation where you end up deciding whether a Story has been accepted or not by what (non PO) customers say at the Sprint Review, then you'll generally have stories that carry over and carry over and carry over and are difficult to get "accepted."
I'm in the process of writing an article about the user story lifecycle (I essentially say that a User Story can proceed through different "levels", or phases). Here is a pertinent snippet(be sure and see the 2nd paragraph):
In the Acceptance level, the main goal is to get the PO to agree and accept the User Story's functionality as complete and correct, as judged against the User Story's Acceptance Tests. Like many things in Scrum, this too is a collaboration, but since the Product Owner is responsible for product vision, the decision is ultimately up to them.
Acceptance technically can only really happen when a complete potentially shippable product increment is available for release(release need not happen for acceptance to occur, though). Having said that, many teams do acceptance in two steps. One step is a more informal acceptance by the Product Owner during the sprint, as soon as the story is completely implemented. If the Product Owner approves, they are then basically saying, "Ok, I agree that this story appears to be complete and correct, and assuming it still appears complete and correct in the final integrated potentially shippable increment, I'll give my final acceptance at that time." In other words, the Product Owner has to verify that the story works correctly once integrated with the rest of the stories implemented that sprint. This second step is at the end of the sprint, once the entire increment(including all implemented stories for the sprint) is fully integrated, tested, and available for release. The second step usually happens just before the Sprint Review, but could happen earlier than that if the increment is delivered early.
One thing you might want to note about this level is that I do not ever say anything about acceptance happening during or just after a Sprint Review. Acceptance occurs between two parties and two parties only: The Product Owner and the dev team. This acceptance should occur *prior* to the Sprint Review. There are a couple of reasons for doing acceptance before the Sprint Review. First, the Product Owner should be leading the Sprint Review (assisted by other members of the Scrum Team if the PO so desires). It's difficult for them to lead the Sprint Review and be analyzing the stories for acceptance at the same time. Second, the acceptance scrutiny given by the Product Owner to the Sprint increment will allow the Product Owner to speak intelligently at the Sprint Review about the implemented functionality, including any known bugs or interesting bits of behavior. Thirdly, you don't want to get into a situation where the Non Scrum Team(NST) stakeholders have a direct impact on acceptance. If the NST stakeholders have feedback about how the stories are delivered or what changes should occur, that feedback should be communicated to the Product Owner as new User Stories that will go on the backlog. It is perfectly fine, though, if a collaboration happens *at or after* the Sprint Review about these new User Stories (that might or might not be changes to the just delivered functionality). Further, the Product Owner has the ability, if they so desire, to prioritize those "follow on" stories right up to the top of the backlog, and introduce them at the soon to be had Sprint Planning Meeting for the very next sprint. Hopefully this late entering story situation will become fairly rare over time, but we have to remain agile and be accepting of late breaking changes.
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
- << Previous post in topic