Does the Definition of Done involves the Product Owner
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.
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
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.
Thank you for your answers I'll discuss of that with my team and I'll come back if I have any more questions.
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.
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.
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 !
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.
Can anyone help me answering this ..
When is the defination of done decided ?
I assume it must be during sprint planning? Any views..
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
Thanks Chris for the inputs.. Can you please explain a DOD with an example that will be a better way to learn a DOD?