Skip to main content

Does the Definition of Done involves the Product Owner

Last post 06:30 pm March 21, 2018 by ashish agarwala
10 replies
02:33 pm January 20, 2014

Hi all,

I've found a similar topic but which doesn't address my particular concern.
In fact I was wondering, if in the Definition of Done for our team, it was a good idea not to mark an item of the product/sprint backlog as done until it have been demonstrated (and approved) to the Product Owner.
Therefore, after having the code, the tests, the Acceptance Criterias fullfilled, we'll keep items In Progress until the PO will have seen the demo of these items. If he approves its state, we'll mark the item as done, otherwise still in progress if he wants us to change something.

What are the pros (if they are pros) and cons?

Thank you very much.


02:56 pm January 20, 2014

Hi

This is how i would approach it, possibly people may have other thoughts.
If the definition of done is nailed down and water tight its not negotiable later in the sprint.
You should not have to change anything if its in accordance with your definition. If you don't do this you may never complete anything as the PO could say make change 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20........
DOD is what it is, its either done or it isn't done, but that is according to what is agreed not what fits the PO post agreement. Educate the PO on why, as you may never finish any task if the PO is having a bad day or a perfection drive, It could also impact on the team negatively and that's not a great thing.

Michael



01:01 am January 21, 2014

Tasks on the Sprint Backlog are owned by the Development Team and as such it is their responsibility to determine when they are Done.

The Product Owner seeks a usable increment of value that meets the Sprint Goal. When an increment is accepted by the PO then the Product Backlog can be revised and resized, hopefully resulting in a burndown.

In other words, each Product Backlog Item is a placeholder for work that is to be "done" in order for an increment to be accepted. Those placeholders themselves do not get "done", they just appear and disappear on the Product Backlog and their scope and size may change.

Having said that, some teams do follow a convention of marking PBI's (e.g. user stories) as "story done". This indicates that the PO has accepted the relevant portion of an increment as being functionally complete. Since the PO is responsible for PBI's, including their revision or retirement, only he or she can assert when these placeholders are "done"...although the Development Team are responsible for resizing any that remain.


03:04 am January 21, 2014

Thank you for your answers I'll discuss of that with my team and I'll come back if I have any more questions.


08:19 am January 21, 2014

If the team is self organizing then usually there is no need to keep the items "in progress".

Sprint backlog items with status DONE means "Ready to be Shipped". Thus it's better to use this after the PO has accepted the Sprint. Although there are more intermediate statuses possible like "Tested", "Ready for Demo".

Definition of done should be decided with the Scrum team and PO.


01:51 pm January 21, 2014

All,

Few more thoughts on this process..
Scrum Team collaborates and agrees on "Definition of Done" (PO is part of the Scrum Team).

As far as ownership of the product backlog Items are concerned,
1. Sprint Backlog Item or story with acceptance criteria is owned by the Product owner. If you are using the Visual Studio for Scrum, you would see statuses like New, Approved, Committed and Done.

The way our team uses is like this
New - When a product owner creates a story
Approved - When the story description and Acceptance Criteria is approved by the stakeholders.
Committed - When the Development Team committed to that story during Sprint Planning
Done - When PO accepts that the story is complete during Sprint Review.

While the Scrum Team are encouraged to show demos through the sprint execution, normally the PO waits until the review meeting to mark the story/backlog item as "Done"

Tasks under the story are owned by the development team.
Development Team has the liberty to mark the items under the story as complete/done, they don’t need to wait for PO to confirm. This is important that items are marked complete as and when it is done, so that the Burndown chart makes sense.


05:58 am January 22, 2014

Thanks, it is good to see that it raise the same questions to other people than us :)

@AG it sounds like a good idea especially as we are using TFS to store our stories. Thanks for that idea !


12:46 pm January 30, 2014

We have used the same strategy as @AG mentions although with different tools. Eng would mark the story as completed and As a PO I would attend the sprint review meeting and make sure that most of the A/C criteria are hit. This would allow the Eng team to get the story points for velocity. I would then separately go through the A/C in more details mark the items as accepted. This could be delayed and go a few days into the next sprint.


10:06 am March 20, 2018

Can anyone help me answering this ..

When is the defination of done decided ?

I assume it must be during sprint planning? Any views..


10:04 pm March 20, 2018

The Definition of Done (DoD) is owned by the Development Team, and may take input from the Product Owner.  The Development Team needs to decide what their DoD is before the first Sprint starts, so before their first Sprint Planning event.  The DoD will add transparency to the other events, for sound decision making.

The Development Team should review their DoD in future Sprint Retrospective to see if they can make it more stringent over time, as they grow as a team and their engineering practices evolve.

Scrum on

Chris


05:51 am March 21, 2018

Thanks Chris for the inputs..  Can you please explain a DOD with an example that will be a better way to learn a DOD?

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.