Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Does the Definition of Done involves the Product Owner
Last Post 30 Jan 2014 07:46 AM by Sandeep Kamat. 7 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Guillaume G
New Member
New Member
Posts:3
Guillaume G

--
20 Jan 2014 09:33 AM
    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.
    michael
    Basic Member
    Basic Member
    Posts:132
    michael

    --
    20 Jan 2014 09:56 AM
    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


    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

    --
    20 Jan 2014 08:01 PM
    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.
    Guillaume G
    New Member
    New Member
    Posts:3
    Guillaume G

    --
    20 Jan 2014 10:04 PM
    Thank you for your answers I'll discuss of that with my team and I'll come back if I have any more questions.
    Anjana Saxena
    New Member
    New Member
    Posts:6
    Anjana Saxena

    --
    21 Jan 2014 03:19 AM
    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.
    Annamalai Ganapathy
    New Member
    New Member
    Posts:3
    Annamalai Ganapathy

    --
    21 Jan 2014 08:51 AM
    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.
    Guillaume G
    New Member
    New Member
    Posts:3
    Guillaume G

    --
    22 Jan 2014 12:58 AM
    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 !
    Sandeep Kamat
    New Member
    New Member
    Posts:21
    Sandeep Kamat

    --
    30 Jan 2014 07:46 AM
    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.
    You are not authorized to post a reply.


    Feedback
    seo