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

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

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

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

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

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”

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

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)

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

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

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!

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

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

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

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, e-mails 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.

https://www.scruminc.com/definition-of-done/