Alternative Text Dave Harris | 08 December 2021 |

Three easy steps to begin building in quality

At DeeperThanBluE UNIFY, we build in quality to transform online business presence. By applying industry best practices throughout software development, we ensure that each element, at every increment, meets regulatory and quality standards.

So, how do we do it? The Agile Manifesto states, “Continuous attention to technical excellence and good design enhances agility”. And what does this involve?

Let’s look at three easy steps to begin building in quality:

  1. The Definition of Done (DoD) is an essential standard to ensure an “increment of value” can be considered complete
  2. The Definition of Ready (DoR) communicates the standards required to make an upcoming element actionable.
  3. INVEST by design facilitates breaking work into “increments of value”; these are small pieces with testability at their core that are essential for supporting Lean Agile thinking (agility).


Applying tools such as these, promotes a framework for the application of business-driven development (BDD), test-driven development (TDD), test-first, frequent integration through the continuous delivery pipeline, agility, and adaptability.

Here we’ll look at each in detail and provide an essential checklist for each.



Definition of Done 

An industry standard good practice document constructed by the ART (Agile Release Train) usually during Sprint or PI planning, to agree the documented standards by which they will demonstrate assurances that artefacts and larger increments of value can only be considered finished when they demonstrate the agreed level of quality and completeness.

These agreements align teams around what quality means and how it is built into the solution.

  • A set of documented considerations which have been met to enable the Scrum team confidently to state they have produced potentially shippable product.
  • All the essential activities are complete when a user story is really done (ready to be released), considering MoR (Management of Risk) and Resolved Owned, Accepted, Managed (ROAM).


Definition of Done exemplar checklist

    • Acceptance criteria met and capabilities completed by all ARTs
    • Acceptance criteria met in completed features
    • Acceptance criteria met by stories
    • Acceptance tests passed
    • Accepted by product manager
    • Accepted by solution manager
    • All defects/bugs subject to MoR (Managed Owned Accepted Rejected) – No must-fix defects
    • All requirements (functional and non-functional) met
    • All standards met
    • All issue types (e.g. stories) subject to MoR
    • Approved by solution and release management
    • Assets are under version control
    • Automation has been applied and utilised supporting acceptance testing using novel ID or Name
    • Cumulative unit tests passed
    • Deployed and installed in the staging environment
    • Documentation created and Version Control System (VCS) certified
    • Documentation supporting the release complete
    • E2E integration and solution validation and verification complete
    • Engineering standards follow
    • Included in build definition and deployment process
    • Increment demonstrated feedback achieved
    • Regression testing performed
    • Solution demonstrated and feedback achieved
    • Stories accepted by product owner
    • Stories ratified & completed by all ART/teams and integrated
    • System E2E integration, validation and verification completed
    • Unit and component tests coded, passed, and included in the BVT (Build Verification Testing)
    • Verification and validation of key scenarios


Definition of Ready

An industry standard good practice document constructed by the ART usually during Sprint or PI planning, to agree that the team is confident that they can successfully deliver the user story, ready to be taken into a sprint, when all the essential activities are complete and a user story is ready to be processed.

The Definition of Ready should not stay fixed. DOR is always a candidate for Retrospective, as it must morph, grow and develop as the team evolves its understanding of what makes a good user story.

Product owners can use Definition of Ready as a guide when preparing for user stories for upcoming sprints. For a team, it is used as a checklist to make sure that there is an increased chance of success in delivering the completed user story, and that enough thought goes into building the user story before they start to deliver it. Definition of Ready brings back the focus to backlog grooming meetings and lookahead planning activities. Definition of Ready helps in minimising the rework on a user story.


Example checklist Definition of Ready for a user story

    • Well-defined INVEST user story
    • Clear, unambiguous, explicit language used
    • User story acceptance criteria defined
    • User story sized by the delivery team
    • Scrum team accepts user experience artefacts
    • Functional requirements criteria identified
    • The person who will accept the user story is identified
    • A team can ‘demo’ the user story
    • Non-functional requirements criteria identified

Example checklist Definition of Ready for a sprint

    • Prioritised sprint backlog
    • Defects, user stories, spikes, and other work the team has committed to are contained in the sprint backlog
    • No hidden work
    • All team members have calculated their individual capacity and commitment for the sprint full time on project (X hours per day)
    • All user stories meet the Definition of Ready
    • Confidence vote completed
    • No blockers
    • Retrospective date defined
    • Showcase date defined
    • Stand-up defined
    • Escalation SLA timescales agreed
    • General reporting agreed
    • Ticket standards agreed (e.g. level of documentation within tickets)



Related to the definition of a good user story, the definitions of INVEST provide a template. A good user story is lean, in as much that its contents promote INVEST, referring to:

Independent – of all others, it has been distilled from other features, contains only a single feature

Negotiable – criteria may be added or removed

Valuable – it adds value to the MVP

Estimable – how long it will take to deliver

Small – it will fit into the sprint

Testability – even if the testing is TBC

Without the INVEST considerations, pushbacks can be expected



    • Story can be developed independently from other stories
    • Refined to get a functional cohesion
    • If there are dependencies, they were refined and separated.
    • One team can work on it with minimal or no dependencies on other teams.
    • One team member can complete the work with minimal or no dependencies on others.



    • The story was discussed with the team, and they understand what to do
    • The acceptance criteria is defined
    • There is a high-level technical solution
    • The team has what they need to start working on the story, but some details will be discovered during the development
    • A/B variants are defined



    • The priority in the backlog is clear
    • Prioritised using MoSCoW (Must, Should, Could, Wont) method
    • The value of the story is quantified
    • The team understand why we do this and the impact on the user
    • The role who obtains the value of the story is clear
    • The stakeholders (would) agree with the acceptance criteria and value
    • It is clear if should be part of the next product increment or MVP (minimum viable product)
    • Hypothesis/experiment, expected result, metrics and measurement period is defined
    • Return on investment: Stakeholders and product owner know how much they will obtain from this story
    • As <Role> I want <Feature> so that <Benefit> title template
    • As <Role, Feature > When < Action > Then <Expected behaviour>



    • Team planning poker session complete
    • Estimated in t-shirt sizes
    • Estimated in story points by the team
    • All stories have similar size



    • Estimation size less than or equal to ‘X’ points
    • It is not an Epic
    • It can be completed in one sprint
    • Refined to obtain 80% of its value using 20% of its effort: The minimum size that can reach value was achieved



    • The team understands how the story can be tested
    • Acceptance tests and examples are defined
    • Given <Role, Feature > When < Action > Then <Expected behaviour>


At UNIFY, we tailor quality solutions to fit the customer. Whether the journey is transforming an approach to quality, software delivery, testing, tooling, we have subject matter experts to help. Get in touch below to learn more.

Related Articles

These might interest you

Software Testing - 06 January 2022

Develop the ultimate accessible online presence with WCAG

At DeeperThanBlue, we coach businesses to develop their online presence, enabling access to new markets and embracing legislative requirements to Read More
Food for thought, Software Testing - 23 November 2021

“Business!” cried the ghost of Jacob Marley: A DTB Christmas Carol

As we approach the festive season and we reflect on the past year and plan for 2022, many businesses will Read More
Software Testing - 04 November 2021

Boundary Value Analysis: ISTQB Test Techniques

In the first of our articles detailing ISTQB test techniques, we’re focussing on Boundary Value Analysis. It’s defined as: “A Read More