Skip to main content

DoD across scaled agile

Last post 03:24 am October 3, 2014 by Ian Mitchell
4 replies
02:48 pm October 1, 2014

Is it important for all teams collectively to share one DoD? Can they create individual ones that can meet a 'standard'?


03:55 pm October 1, 2014

The DOD is for the product, not for the team.
If the teams are working on the same Product, then the DODs have to be the same.


04:07 pm October 1, 2014

So a team may have to juggle 2 - 3 different DoD's in 1 sprint. That doesn't make sense to me.


05:32 pm October 1, 2014

DoD is a checklist of valuable activities required to produce software.

Definition of Done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.

DoD is the primary reporting mechanism for team members.

Reporting in its simplest form is the ability to say, “This feature is done.” After all, a feature or Product Backlog Item is either done or it is not-done. DoD is a simple artefact that adds clarity to the “Feature’s done” statement. Using DoD as a reference for this conversation a team member can effectively update other team members and the product owner.

DoD is informed by reality.

Scrum asks that teams deliver “potentially shippable software” at the end of every sprint. To me, potentially shippable software is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion. Products that can be released to end users with two days can be reasonably said to be in potentially shippable state. Ideally, potentially shippable is equivalent to the Definition of Done.

In reality, many teams are still working towards a potentially shippable state. Such teams may have a different DoD at various levels:
•Definition of Done for a feature (story or product backlog item)
•Definition of Done for a sprint (collection of features developed within a sprint)
•Definition of Done for a release (potentially shippable state)

There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release. Ultimately, the decision rests on the answer to the following three questions:
1.Can we do this activity for each feature? If not, then
2.Can we do this activity for each sprint? If not, then
3.We have to do this activity for our release!

DoD is not static.

The DoD changes over time. Organizational support and the team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints.

DoD is an auditable checklist.

Features/stories are broken down into tasks both during sprint planning and also within a sprint. The DoD is used to validate whether all major tasks are accounted for (hours remaining). Also, after a feature or sprint is done, DoD is used as a checklist to verify whether all necessary value-added activities were completed.

It is important to note that the generic nature of the definition of done has some limitations. Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis. For example, following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature; however, for other features within the system that dointerface with a human being, those user experience guidelines must be followed.

Summary

The definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive checklist of necessary, value-added activities that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release)


03:24 am October 3, 2014

The Definitions of Done used by each team that contributes to the delivery of an increment should be compatible, as this asserts the quality of the product and is a factor in establishing the potential for release.


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.