Forums

By posting to our forums you are agreeing to the Forum terms of use.
Product Owner and the Definition of Done
Last Post 27 Mar 2013 08:43 PM by Susanta. 7 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Resolved
Francisco Rodríguez
New Member
New Member
Posts:8
Francisco Rodríguez

--
22 Mar 2013 01:02 PM
    Regarding the Definition of Done, does the Product Owner provide any input on it? I've read that the responsibility of this definition lies solely on the Development Team, but I think the PO may provide criteria that must be followed, like supporting material (i.e. help content for each PBI), or testing strategy (i.e. usability or performance).

    What do you think?

    Thanks!
    JackOLantern
    New Member
    New Member
    Posts:12
    JackOLantern

    --
    22 Mar 2013 01:17 PM
    The development team is solely responsible for the DoD. The PO can create backlog item "requirements" that the application perform at a certain level, or that it be extensible in particular ways, or whatever. The PO, however, can not tell the development team how to do its business.

    The job of the development team is to write high-quality, high-value software. The PO decides what the value is, and the development team decides what the quality is. If the PO gives feedback that the product sucks because it's buggy, slow, hard to use, etc., then the dev team has to take that into account and change the way they produce software, but it's very much not in the PO's purview to tell them HOW to accomplish that.
    Philipp Eisbacher
    New Member
    New Member
    Posts:31
    Philipp Eisbacher

    --
    22 Mar 2013 01:22 PM
    The Scrum Guide talks about the scrum team, being owner of the DOD, so the PO is included.

    For me it is something like a "contract" between Development Team and PO and as in any contract, both parts can provide input until both are ready to "sign" it.

    For something like performance goals, you can also use "constraints". Those are types of userstories that are not estimated on not pulled in the Sprint Backlog but are there to remember such things like "be compatible wit h all IE beck to 8" or something like this. Because if you have many of them they will blow up your DOD and there will be PBI's that will not meet the DOD because the are not in the same context,
    Francisco Rodríguez
    New Member
    New Member
    Posts:8
    Francisco Rodríguez

    --
    22 Mar 2013 02:03 PM
    @Jack:

    I think the main issue here is quality. I believe the PO may state some quality aspects, namely, the aspects users are aware of (extrinsic). As you said, the job of the development team is to write high-quality, high-value software; but some quality aspects that affect value should be agreed with the PO, as Phillipp said.

    Regarding specific PBIs related to quality, some quality attributes can be stated this way (i.e. documentation) but others should be stated as required for all stories (i.e. performance or usability). In that way, PO can tell to the team to accomplish those attributes, so they may decide to include that in DoD.

    I think DoD may be viewed similarly to PB, but reversed: PO can provide input, but Team is responsible for it.

    Thanks!
    JackOLantern
    New Member
    New Member
    Posts:12
    JackOLantern

    --
    22 Mar 2013 02:18 PM
    • Accepted Answer
    @Francisco, I think you've got it right. The PO can provide input, that's where I was going with the PBIs regarding perf and quality, and those would naturally require a DoD that can accomplish these goals. But it's the dev team that decides how to do it. The PO can't say "you have to have perf tests that are run x often", but CAN say "the application has to perform in x way, go figure out how to make it do that".
    JackOLantern
    New Member
    New Member
    Posts:12
    JackOLantern

    --
    22 Mar 2013 02:18 PM
    @Francisco, I think you've got it right. The PO can provide input, that's where I was going with the PBIs regarding perf and quality, and those would naturally require a DoD that can accomplish these goals. But it's the dev team that decides how to do it. The PO can't say "you have to have perf tests that are run x often", but CAN say "the application has to perform in x way, go figure out how to make it do that".
    Francisco Rodríguez
    New Member
    New Member
    Posts:8
    Francisco Rodríguez

    --
    22 Mar 2013 06:11 PM
    @Jack, thanks for your insights. The issue is much clearer to me right now.

    Cheers!
    Susanta
    New Member
    New Member
    Posts:20
    Susanta

    --
    27 Mar 2013 08:43 PM
    I believe PO must have input to the definition of DoD - he is the one who is going to take that to business. So he must have something that was not meant by dev team while defining. So definition is PO + Dev team while responsibility to deliver as per DoD goes to Dev team.
    You are not authorized to post a reply.


    Feedback