1. Johanna Rothman Know What “Done” Means Chapter 11
Copyright © 2017

2. What does “done” mean to your project?
Rothman
The project met its date or scope commitments… and there were not too many problems
The project met its release criteria… meaning the project is done and the software is “shipped”
The project team is done and others package the product and release it
What tactics are used to build confidence in the release?
Prescribed release criteria may be used…
Whatever criteria that provides confidence in the value to be delivered

3. The team should know what done means at the release level for each feature set of stories!
The difference levels of “done”
“done”, “done-done” and “done-done-done”
“done” for a story being done
“done-done” for a completion iteration
“done-done-done” for a release
or better yet – have the product in a releasable state at any time
Rothman suggests managing the “done” problem as follows:
The story satisfies its acceptance criteria
The story meets the team’s standard for technical excellence
The Product Owner agrees the accept the story

4. Define Acceptance Criteria for Each Story!
When the team “finishes” designing and developing the functionality for a story…
… meaning the story’s acceptance criteria have been specified and met…
An appropriate a scenario for each story exists…
Given its context for use
When and how some action is carried out
With some set of observable results demonstrated

5. Rothman: What “done” means for a story as a working agreement
All the code is checked-in
There are automated unit tests
There are automated system tests at the API level
All the automated tests are checked-in
All the tests pass
The documentation for the feature is complete
There has been some sort of paring or other eyes reviewing the code and automated tests to prevent shortcuts
Rule of Thumb: specify what “done” means as a working agreement… so no shortcuts are taken

6. Without a definition of “done” for each iteration…
… there is high probability of risk from an accumulation of technical debt and … as a result being overwhelmed by the possibility of an increased amount of technical debt … the “un-done” state … and the likelihood of a “death march” to actually get to “done”

7. Understand When Customers Can Take Your Releases
Customers (or Product Owners) may only what fewer new releases once …
Why?
They may want to “certify” or run the new product through some quality checks before rolling it out to customers or the organization
They may have “local (in house)” changes to be integrated into the new version of the product
They may want to reduce any potential disruption caused by the new version

8. Different ways to do the release…
As internal releases that are used internally in order to understand the product direction … and for demos
As incrementally grown releases in order to attract new customers
As “real” finished releases taken by customers
Releases may be incremental… for example, once a month or once a quarter or every six months
See the insert: “We Differentiate Our Releases” (page 169)

9. Building a Product Toward “Real” Doneness
Assessing the “nonfunctional” requirements (how the software should “behave” during its use)
… to ensure that the product acts in a way that will satisfy the customer
… that is, without problems with its usability, reliability, security and overall performance
How to move from acceptance criteria in the small to overall performance (acceptance) criteria…
Build and use automated tests
If a large story is of “epic” dimensions, performance acceptance criteria for that story needs to be me

10. Recognize “Done” Traps
When teams do not realize the problems
No “done” criteria have been agree upon
Everything needs to be “done” before anything can be released
The team requires “hardening” iterations or effort
The consequence being that teams do not release anything in a “timely” manner

11. 1. No “done” criteria have been agree upon
To deliver value.. teams need to know what “done” means at various levels…
for the story
for the iteration
for releasing
for the project
The team needs working agreements or criteria to know what “done” means!

12. 2. Everything needs to be “done” before anything can be released
Causes
Teams cannot get feedback until they actually release something
The can’t release something until everything is “done”
… why, the deliverables are large and can’t be completed in a single iteration
The obvious solution should have been to create small stories…
… and also experiment, as needed by “building” a Minimum Viable Product (MVP) or a Minimum Viable Experiment (MVE) to get unstuck from large stories

13. 3. The team requires “hardening” iterations or effort
Why? … because of the lack of acceptance criteria needed to assess implementation of one or more stories … and or the team is unable to finish the work scheduled for an iteration The consequence being the inability of the team to finish work with result of adding work to subsequent iterations

14. Teams should fix problems as soon as they are discovered!
This is technical debt that might be categorized as done
What to do…options:
Use a retrospective to understand what happened and what needs to be done
Pay attention to estimations and effort… for example, are shortcuts made in order to “squeeze” more into and iteration
Assess the “done” criteria… the goal needs to work towards achieving quality/technical excellence in all the work that is done.
Rule of Thumb: Teams failing to satisfy its done criteria need to reduce the work… the size of stories added to the Sprint Backlog
The goal is to incrementally truly finish the work in each iteration… and not to increase Technical Debt and/or reduce the quality of the work

15. Scrum Inc. Definition of Done
For software “Done means coded to standards, reviewed, implemented with unit Test-Driven Development (TDD), tested with 100 percent test automation, integrated and documented.” In a services context, it might look something like: "Done means every task associate with a User Story has been completed and allows the Product Owner to review and make sure it meets his or her expectations." At Scrum Inc., a business services organization, this can include word documents, excels sheets, presentation decks, s or any number of other work produced. In order for the Product Owner to accept the story these elements need to be attached to the User Story for it to be called done. The Definition of Done ensures everyone on the Team knows exactly what is expected of everything the Team delivers. This ensures transparency and quality that fits the purpose of the product and organization.