Client acceptance as part of the definition of done?

I see a different problem here - missing Collaboration between the Dev Team and PO. The role of PO is not accepting/rejecting the Increment, he should work with the Dev Team daily throughout the Sprint, whenever required. Remember the Agile principle# 4 - "Business people and developers must work together daily throughout the project"

The worst thing for a PO/Dev Team is gettint surprises during the Sprint Review.

Burndown charts may be optional but including acceptance by PO in DoD make sense to me.

@Andreas, ideally the Product owner represents the customer, he is the one who understands the customer needs and work with dev team to get it done. The PO is responsible to accept the user stories.

Coming to the definition of done - If your client feedback is one of the item in DOD, then you must include the customer in Sprint review meeting, otherwise remove the client feedback from DOD. Sprint goal is only met when DOD met, otherwise no.

The Development Team should have all of the skills necessary for producing a Done increment. Any estimates they produce should take inro account all work needed to meet the DoD.

If the PO is not a membee of the Development Team, is it then reasonable for the team to use a DoD which is dependent upon his or her approval? How can they commit to a level of Done which is not fully under their control, or estimate the work that will be needed?

You seems to know the root cause of the issue as you said 'Stories are not defined well enough.'.
The Dev team in this case should raise it to PO before committing to deliver, as this is not happening there is a gap between what they think is done but rejected by PO.
If small portion of stories are rejected, should be ok to refine and putback to PB for subsequent sprint, but if it is happening for most, then a serious issue and POO should consider rewriting it. Scrum master plays key role of facilitating and coaching PO how stories needs to be written and the Dev team can support by stating the level of details required.

Also, PB grooming sessions plays key role wherein po and dev team collaborate to ensure it is looking goid.

Regards
Pankaj

Do you have a PO for your team? If so, then they need to work harder and closer with the client to understand the requirements.
If not, then maybe you need one - or..... more radically, ask the client to provide a PO for your team.
Scrum is about collaborative working... throw the ball back in their court maybe...

Posted By Ian Mitchell on 10 Jan 2017 06:26 AM
The Development Team should have all of the skills necessary for producing a Done increment. Any estimates they produce should take inro account all work needed to meet the DoD.

If the PO is not a membee of the Development Team, is it then reasonable for the team to use a DoD which is dependent upon his or her approval? How can they commit to a level of Done which is not fully under their control, or estimate the work that will be needed?

Hi Ian, could you elaborate on this?

I'm not sure what you're implying.

One of our team's DoD's has the item 'A story is Done if it has been demonstrated to the PO' and the 'A story is Done if it has been reviewed by the PO'. We don't specifically call for 'approval' but it's implied in some capacity.

@Andreas Is the client acceptance process telling you whether the client likes the delivered functionality or is it to do with quality or delivering according to specs?

DoD is one thing and internal to the team. If users will actually love the features delivered is something different.

I've read some discussions (cannot find source) where different levels of done was discussed e.g.

1. Done - Done according to the teams DoD, e.g coded, checked in, accepted by PO etc.
2. Done Done - Done and delivered to users.
3. Done Done Done - Done, delivered to users and feedback gathered.

You need to get to step 3, often it stops at 2.

The Development Team are the ones doing the work to meet the DoD. By definition the PO is *not* doing any of that work unless he or she is also a Development Team member.

Therefore if PO approval is in the DoD, and the PO isn't a Development Team member, then not all of the work that has to be done is under the Development Team's control. It then becomes difficult for that team to forecast work for completion or to commit to a goal.

Posted By Alex Crosby on 11 Jan 2017 09:11 AM

One of our team's DoD's has the item 'A story is Done if it has been demonstrated to the PO' and the 'A story is Done if it has been reviewed by the PO'. We don't specifically call for 'approval' but it's implied in some capacity.

I like this.

The points above saying that if PO is not part of dev team, acceptance by PO can't be part of DoD - ask for PO etc. Makes sense.

In this case, I think I am the PO. I'm also the scrum master. I think I read a post about why project managers don't work in Agile - guess this is why.

It's hard to respect scrum rules, and if I do I and put down the effort to maintain it, I don't have time to do the PO work properly (which is like business analyst work IMO).

So this question stems from: "Hey, I don't have time to be a good PO, so I delegate basic acceptance to my stakeholders and pretend we don't have a PO. What do I do without a PO?"

Probably solution here is to outsource scrum master roles to devs in the team. Or at least part of what a scrum master does..

Hi,

I see in several responses it's being questioned if the PO is part or not part of the Development Team. My understanding is that the PO is part of the Scrum Team, not the Development team. 

The Development team should come up with the DoD based on the PBI that are being considered for the Sprint. The Development Team and PO should have a conversation on the DoD and agree on it.

The DoD is taken into account when pointing the User Stories in the Sprint Planning meeting.

Based on this, in the DoD I'd include a bullet that says 'Meets acceptance criteria stated in the User Story' and leave the PO acceptance out of it as this is an activity that happens sometimes before the Sprint Review or during the Sprint Review.

I agree with comments that the issue seems to be related with user stories not being clearly defined.

The user story could be clearly defined and still leave some room for discrepancy between software functionality being delivered and the acceptance criteria. This could be just because Acceptance Criteria is a high level description of the criteria. The details of functionality is described in SW requirement specifications, test specs... which cover details of the baseline on top of which US is being completed. Therefore inspector has to review conducted test report/logs and  check if all relevant parameter permutations (that vary from US to US) were covered. It is not practical to run test on all possible permutations so DT limits scenarios on their test plans. The PO as a Customer representative has to verify that all passing all tests relevant to the Customer were passed by inspecting plans and execution  logs. So there has to be an acceptance step for this activity and it might result in PO (inspector) to determine that Acceptance criteria was not satisfied  based on minute detail specific to a US (not necessarily in current DoD) not captured in the US AC section.

So should not there be formal step for PO to inspect evidence materials created by  DT's claim of meeting AC? Why is the Sprint Guide mentions "PO acceptance" only for the cancelled Sprint:

"When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it." ?

So should not there be formal step for PO to inspect evidence materials created by  DT's claim of meeting AC? Why is the Sprint Guide mentions "PO acceptance" only for the cancelled Sprint:

If the Sprint Goal has been achieved, shouldn’t the PO be able to trust that the Development Team have met the Definition of Done, and that the increment provided is of release quality?