Three Levels of Doneness

November 21, 2016 — Posted by Ken Pugh

How do you know when you’re done with something?   With software applications, there are at least three levels of doneness – business, customer/user, and technical.    There are different metrics for doneness at each level.  Tests at each level can help create an unambiguous definition of done for that level.    

An Overview

Here’s a diagram of the different levels.  The large circles represent the system, before (“as-is”) and after the change (“to-be”).  The person is a user of the system.   The inner circles represent the modules of the implementation of the system. The levels are explained in the following sections. 

Three levels of tests

Business Tests

At the business level, the doneness test revolves around whether the business value of a particular capability or feature has been achieved when going from the “as-is” system to the “to-be” system.  Business value can include increased market share, increased revenue, decreased expenses, and increased customer satisfaction (more promoters and less detractors).  The exact details of a capability or feature necessary to attain the business value may not be known.  They may come from marketing and sales or internal business departments.       

Lets’ give an example.  Acme’s GPS Mapping software has a 1% market share.   They want to increase this to a 2% market share.  That’s the business doneness test.     

Marketing believes that an additional compelling feature, an errand planner, can accomplish this.  Errand planner maps the shortest or quickest route through a set of places that one needs to go and determines the sequence in which to drive.   If deploying the basic errand planner does not pass the business test, then the business might try an advanced version of errand planner that accounts for the timing of traffic lights and the type of turns (right or left). 

Business tests are created by the business prior to a feature being detailed.   They may not necessarily pass until the “to-be” system has been deployed for a while.   In some cases, the test may pass due to other business environment factors, not the implemented feature.  For example, a viral YouTube  video with a celebrity using the application might be the real reason for the increased market share.

Customer/User Tests

At the customer/user level, doneness concerns whether the particular item being developed is potentially ready for deployment.   The doneness tests are the acceptance tests provided by the customer and users.  These customer/user tests are usually stated as an interaction between the user and the system with enough detail that they are unambiguous. 

In our example application, a customer/user test would be whether the shortest route between all the errand locations was found correctly.   These tests are often expressed in a given/when/then format.  Here’s an outline of an example test:

Given a set of destinations:



Grocery store

1 Pepperoni Street

Shoe repair shop

20 Sole Drive


30 Dry Court


1 Aqua Lane

When the shortest route is computed from my house

Then the route is:

Shoe repair shop


Grocery store

Customer/user tests are created by the triad (product owner, developers, and testers) prior to an item being implemented.   It is necessary that they pass before an application is deployed.   Note that there are usually other aspects of the application (security, user experience) that must also be tested before deployment.

Technical Tests

At the technical level, doneness is about whether a particular module performs according to the design of the system to pass the customer/user tests.  Technical tests can revolve around a single method, a set of methods, or combinations of components.   They are created by the developers, architects, and others involved with the implementation.   They must pass before the application is ready for the customer/user tests.   An outline of a technical test for one of the modules that will implement the errand mapper could be:

Given two locations

1 Pepperoni Street

20 Sole Drive

When the shortest distance is computed

Then the value should be 1.2 miles.

This module would be used in combination with other modules to form the implementation that will pass the errand mapper test.  


There are different types of tests for doneness at each level – business, customer/user, and technical.  If you start with an agreed upon doneness test, then determining when done has been achieved will be easier for all.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives ( He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban