How to Ensure your Definition of Done is Well Done not Half-Baked

© 2018 Cognizant
© 2018 Cognizant
May 23, 2018
How to Ensure Your “Definition of Done” is
Well-Done not Half-Baked
Susan Schanta, Director

© 2018 Cognizant2
Table of Contents
Definition of Done
Key Elements to Establish your Definition of Done
Are the User Stories in Your Product Backlog Sprint Ready?
User Story Samples
Final Words
Appendix

© 2018 Cognizant3
Definition of Done

© 2018 Cognizant4
The Importance of a Well Done Approach
The Half-Baked Philosophy
 Adopt Agile Methodology
 Deliver software with increasing frequency
 Everything will be faster and better
The Well Done Philosophy
 Definition of Done defines shared commitment for
quality
 Balance speed to market with repeatable, acceptable
quality output
 Improve accuracy and velocity
 Apply standards for acceptance criteria for user stories.
 Improve estimation accuracy, sprint execution and
delivery of working software frequently
Agile is the catalyst to software delivery
Definition of Done = Quality + Velocity

© 2018 Cognizant5
Definition of Done
The Definition of Done measures the quality not the functionality
 Ensures Product Owner and Development Team agree on the definition of quality
 Used to evaluate whether value was added when activities are completed
 Universally applied to all Sprints
The Definition of Done ensures software is fit for the purpose
 Defines quality standards for shippable software
 Outlines what business qualifies as “value”
 Avoids redo work and technical debt
 Drives transparency
 Acceptable end state for deliverables
 Condition of Satisfaction for PBI item readiness for Sprints
Potentially Shippable Software

© 2018 Cognizant6
Why Do I Need a Definition of Done?
 Sprints do not deliver value or deliver less value than desired
 Team lacks shared definition of value
 Planned work is not completed by the end of the Sprint
 Technical Debt
 Redo work
 Inconsistent velocity
 Traveling user stories
 Lack of transparency
Definition of Done Establishes Success Criteria for the Organization

© 2018 Cognizant7
Definition of Done – Benefit to the Organization
The Definition of Done communicates the
organization’s shared commitment to quality
 Ability to deliver working software frequently
 Achieve consistent velocity with standard of
quality
 Velocity is driven by information and discipline
 Achieve operational transparency
 Define software fit for purpose
 Product Owner and Scrum Team are equal
partners in delivering quality
Balance speed to market with exceptional quality while managing cost restraints

© 2018 Cognizant8
Key Elements to Establish Your Definition of Done

© 2018 Cognizant9
Organizational Definition of Done
 We will implement a Lean Agile framework to drive the Agile process
 We will adhere to processes that drive and result in quality
 We will remove activities that hinder velocity
 We understand our role in the team and respect the roles of others
 Product Owners define the “What” in the form of user stories
 Development Team determines “How” to deliver software that meets the conditions of satisfaction
 The Development Team will develop quality software that is potentially shippable every Sprint
 Software is verified against the User Story’s acceptance criteria and conditions of satisfaction
 The Product Backlog is prioritized based on defined value
 Commercial value
 Core functionality is prioritized higher than enhanced features
 Supports the business

© 2018 Cognizant10
Definition of Done – Product Backlog Management
As a Product Owner, I will ensure that User Stories are clearly defined so the
Development Team understands them
 User Stories address functional behavior
 User Stories address nonfunctional behavior
 User Stories are specific to a single user
 User Stories adhere to INVEST
 User Stories are small enough to fit into a Single Sprint
 User Stories have Acceptance Criteria
 User Stories have Conditions of Satisfaction

© 2018 Cognizant11
Definition of Done vs. Conditions of Satisfaction
Conditions of Satisfaction
 Only users with credentials can log in
 Users who don’t have credentials are denied
access
 Users can set profile to remember user name
 User is locked out after 3 unsuccessful log in
attempts
 User with credentials can request password
reset
 Request for password reset fails if user does
not have credentials
Definition of Done
 User Stories address functional behavior
 User Stories address nonfunctional behavior
 User Stories are specific to a single user
 User Stories adhere to INVEST
 User Stories are small enough to fit into a
Single Sprint
 User Stories have Acceptance Criteria
 User Stories have Conditions of Satisfaction
Definition of Done for Sprints vs. User Stories

© 2018 Cognizant
Definition of Done – Scrum Team
 Task breakdown for a User Story is completed during Sprint
Planning
 All major tasks are estimated and fit into a single Sprint for the
User Story to be accepted into the Sprint
 Code is complete when all Acceptance Criteria for the User
Story have been met and the Conditions of Satisfaction
demonstrated
 Code is Checked In and all Unit Tests pass; no unintegrated
work in progress
 Code is continuously integrated
 Requirements are traced to Code Implementation
 Automated Regression Tests pass
 Testing across designated platforms tested and passed
 Incomplete User Stories are returned to the Product Backlog
for re-estimation and prioritization for future Sprint
 Outstanding defects are addressed or determined to be
acceptable per quality standards and placed in Product
Backlog for estimation and prioritization for future Sprint
 Product Owner accepts the User Story

© 2018 Cognizant13
Are the User Stories in Your Product Backlog Sprint Ready?

© 2018 Cognizant14
What is the Definition of Done for a User Story?
Definition of Done is universally accepted and applied for all Sprints
Measures quality of work performed
Acceptance Criteria and Conditions of Satisfaction apply to a single User Story
Measures whether user story has been fulfilled

© 2018 Cognizant15
Acceptance Criteria
Acceptance Criteria establish a measurement for pass/fail for the user story. It does not
imply the functionality is 100% complete, only that the user story being addressed is
“done.”
Conditions that a software product must satisfy to be
accepted by a user, customer or other stakeholder.
Microsoft Press
Pre-established standards or requirements a
product or project must meet. Google
Entrance Gate Translation – User Story is Sprint Ready

© 2018 Cognizant16
Why Do I Need Acceptance Criteria?
 Creates the definition for what provides value
 Provides a standard of measurement for “Done”
 Creates clarity of what the end state looks like
 Define the boundaries for what we will develop
 Helps to determine if the user story is too big
 Facilitates accurate estimation
 Provides a measure for whether the user story will fit into the Sprint
 Drive the creation of test cases

© 2018 Cognizant17
User Story Samples

© 2018 Cognizant18
User Story w/Acceptance Criteria Template
As a (user) I want to (function) so that I can (rationale/ achieve some result).
As an internet banking customer
I want to see a rolling balance for my everyday accounts
so that I know the balance of my account after each transaction is applied
Acceptance Criteria
 The rolling balance is displayed
 The rolling balance is calculated for each transaction
 The balance is displayed for every transaction for the full period of time transactions are available
 The balance is not displayed if a filter has been applied
Other User Stories/Acceptance Criteria
 Transaction history when only credits displayed
 Transaction history when only debits displayed
 Transaction history when only checks displayed
On Acceptance criteria for user stories by Sandy Mamoli
http://nomad8.com/acceptance_criteria/

© 2018 Cognizant
User Story Attributes
Independent
 A user story can deliver value on its own
 User stories do not have numerous dependencies
 User stories may have numerous acceptance criteria
 Test cases can be structured to measure whether the desired
outcome is achieved
 User stories are not tied to a technical solution
Negotiable
 The goal/expected outcome of a user story is not negotiable
 A defined, expected outcome is the measure of testable
 The steps of how to execute the test case may vary based on the
technical solution
 How a user story is addressed is negotiable
Valuable
 User stories are customer centric
 User stories are focused on business outcomes
 User stories are not technical tasks
 The test case must emulate the customer workflow and assure the
business outcome
 Test cases may be a combination of business and technical
validation
Estimate-able
 Use stories provide enough detail to allow estimation
 A measure of whether the user story is an Epic or a User Story is
whether you can estimate the work effort
Small
 User stories are small to ensure independence and ability to
estimate
 Small user stories are easier to manage and allow for easier trade-
off in Sprint Planning
 A measure of whether the user story is an Epic or a User Story is
whether the boundaries of test case coverage is clear
 Small user stories make it manageable to adjust test execution
easier
Testable
 User stores have defined acceptance criteria including role, action
and outcome
 User stories can be objectively tested
 Acceptance criteria drives test case creation from a customer
centric perspective because
 User roles are clearly stated
 Inputs and expected outcomes are defined
 Conditions of Satisfaction determine expected outcome for test
cases

© 2018 Cognizant20
User Story w/Acceptance Criteria Template
As a (user) I can (function) so that (rationale/ achieve some result).
Scenario This is the title of the condition to be acted upon.
Given (an initial condition) The user places an item into their shopping cart.
When (something happens) This is where the process in which the user's initial order is verified or whether it fulfills the system
requirements to process the task. If it does, then the system can proceed to work on the order.
However, if the user order does not match to the system requirements, the system will deny the task.
Then (this is the result) Once the system is done verifying the user order, the order is then processed to produce the results
which would be: the final result, input to the next task or a lead-on for the user to the next task.
What Are Acceptance Criteria: Explanation, Examples and Template
from Existek at https://existek.com/blog/what-are-acceptance-criteria/
As an email user, I can send messages to other email users…
Scenario: Sending message through valid email address
Given The email address is valid
When The email address is authenticated
Then The message is sent to the email address
Scenario: Sending message through invalid email addresses
Given an invalid email address
When the email is authenticated
Then the online profile is flagged as incomplete, kickoff snail mail message

© 2018 Cognizant21
User Story w/Conditions of Acceptance
As an email user, I want to reset my password so
that I can login to access my email
Scenario
Selecting a valid new password
Given The password is valid
When The new password is entered
Then The new password is saved
Scenario
Selecting an invalid password
Given The password is invalid
When The password is entered
Then The new password is rejected
What Are Acceptance Criteria: Explanation, Examples and Template
from Existek at https://existek.com/blog/what-are-acceptance-criteria/

© 2018 Cognizant22
Testing the User Story
Test Cases
 Password with 7 characters
 Password with 256 characters
 Password with one uppercase, six lowercase,
two numbers and a special character
(!@#$%^&*)
 Password with no uppercase alpha
 Password with no lowercase alpha
 Password with no number
 Password with no special character
 Password reused
Selecting a valid new password
Given The password is valid
When The new password is entered
Then The new password is saved
Scenario
Selecting an invalid password
Given The password is invalid
When The password is entered
Then The new password is rejected
Acceptance Criteria
 Password must be 8-255 characters
 Password must have lowercase alpha
 Password must have uppercase alpha
 Password must have number
 Password must have special character
 Password cannot be reused

© 2018 Cognizant24
Always Strive for Well Done
 The Product Owner and Scrum Team need a
shared commitment for the Definition of Done to
balance Speed to Market with exceptional
Quality while managing cost restraints.
 Your team can improve Accuracy and Velocity
by constructing a team level Definition of Done
and applying standards for the establishment of
acceptance criteria for user stories.
 Your team will realize long term gains in
Estimation Accuracy and Sprint Execution
as well as increase your ability to deliver
working software frequently.
Agile is not a magic bullet guaranteeing quality and speed

© 2018 Cognizant27
Testing the User Story
Test Cases
 Rolling balance for current period
 Rolling balance with from/to period
 Rolling balance calculated accurately for
debits
 Rolling balance calculated accurately for
credits
 Rolling balance is displayed in right column
 Rolling balance amount has two decimal
places
 Rolling balance is not displayed when checks
only are displayed
 Rolling balance is not displayed when
deposits only are displayed
User Story
As an internet banking customer
I want to see a rolling balance for my everyday
accounts
so that I know the balance of my account after
each transaction is applied
Acceptance Criteria
 The rolling balance is displayed
 The rolling balance is calculated for each
transaction
 The balance is displayed for every transaction
for the full period of time transactions are
available
 The balance is not displayed if a filter has
been applied

© 2018 Cognizant28
References
Levison, Mark. “Definition of Done vs. User Stories vs. Acceptance Criteria.” Agile Pain Relief, Agile Pain Relief Consulting, 30 May 2017,
https://agilepainrelief.com/notesfromatooluser/2017/05/definition-of-done-vs-user-stories-vs-acceptance-criteria.html#.WqVk-nxG202.
Gullo, Daniel. “Definition of Done: User Stories.” Agile Alliance, 15 Nov. 2017, www.agilealliance.org/definition-done-user-stories/.
Z, Maryna, and Dmitriy G. “Clear Acceptance Criteria and Why They're Important.” What Are User Acceptance Criteria [Quick Review with
Examples], https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important.
Levison, Mark. “Definition of Done vs. User Stories vs. Acceptance Criteria.” Agile Pain Relief, 30 May 2017,
https://agilepainrelief.com/notesfromatooluser/2017/05/definition-of-done-vs-user-stories-vs-acceptance-criteria.html#.WrpP-X8h202.
Mitchell, Ian. “Walking Through a Definition of Done.” Scrum.org, 2017, https://www.scrum.org/resources/blog/walking-through-definition-done.
Huether, Derek. “The Definition of Done.” LeadingAgile, 26 Jan. 2018, https://www.leadingagile.com/2017/02/definition-of-done/.
“Backlog Grooming.” Leading Agile, https://www.leadingagile.com/wp-content/uploads/2015/07/Job-Aid-Story-Grooming.pdf.
“Definition of Done.” Definition of Done, The LeSS Company B.V., https://less.works/less/framework/definition-of-done.html.
“What Are Acceptance Criteria: Explanation, Examples and Template | Existek Blog.” RSS, 5 Dec. 2017, https://existek.com/blog/what-are-
acceptance-criteria/.
Novoseltseva, Ekaterina. Definition of Done Examples for Software Projects . Apiumhub, 26 Sept. 2017, https://apiumhub.com/tech-blog-
barcelona/definition-of-done-examples-software-projects/.
“What Characteristics Make Good Agile Acceptance Criteria?” Segue Technologies, 24 June 2016, www.seguetech.com/what-characteristics-make-
good-agile-acceptance-criteria/.

How to Ensure your Definition of Done is Well Done not Half-Baked

In this document

More Related Content

What's hot

Similar to How to Ensure your Definition of Done is Well Done not Half-Baked

Recently uploaded

How to Ensure your Definition of Done is Well Done not Half-Baked