Doneness Focused Processes

December 12, 2016 — Posted by Ken Pugh

In a previous article, I described the three levels of doneness tests – business, customer/user, and technical.   Corresponding to these levels of tests are three processes that are all focused on the doneness tests.   These are Business Test-Driven Development (BTDD), Acceptance Test-Driven Development (ATDD), and Test-Driven Development (TDD).   We’ll see how they differ and how they all relate to Plan/Do/Check(Study)/Act (PDCA).

Here’s a picture of the test levels from the previous article:

Levels of Test

And here’s a diagram of the three process levels:

Process Levels

Business Test-Driven Development / Objective-Based Development

Business Test-Driven Development (BTDD) matches the “TDD” in the other two processes. However, some like to refer to this as Objective-Based Development (OBD).    BTDD/OBD applies the PDCA cycle to software development.  In the Plan phase, the business doneness tests (also called objectives) are created.  These involve the expected business value to be produced by a changing an application from the “as-is” state to the “to-be” state.  Business value includes increased revenue, decreased expenses, and improved customer satisfaction. 

During the Do part, a feature or set of features is developed.  After the new application is deployed, the business test is checked to see if the business value has been created (the Check or Study phase).   During the Act portion, the results of the business test are analyzed.  If the test passes, then a new cycle for a different business value or feature may be started.   If the test fails, then a decision must be made whether to accept the failure and move to something else or to determine what other changes should be tried to make the test pass.   It’s a balance between trying to achieve the business value and the effort required to create it. 

Everyone involved in development should know the business tests and should be informed of their success or failure.   Don Reinersten (a noted author of books on Lean) has said in practice that less than 5% of development teams ever learn of the business test result. From what I have learned in my own informal polls, the percentage may be well less than that. 

The cycle time for BTDD/OBD is longer than a release cycle.   An application must typically be deployed for a while before it can be determined that the business test passes.   The parties that are primarily involved are the business customers – internal departments or marketing and sales.  

Acceptance Test-Driven Development

The Do stage of BTDD involves Acceptance Test-Driven Development (ATDD).  Some refer to this as Behavior-Driven Development (BDD) or Specification by Example (SBE).   In the Plan stage of ATDD, customer/user doneness tests are created for feature scenarios.  In the Do part, these acceptance tests become the context for the technical tests of TDD.   When the implementation is complete, the Check stage ensures that the acceptance tests pass and the user can execute the functionality that the tests represent.   In the Act portion, any feedback from the user can generate additional acceptance tests which become one more cycle of ATDD.   The relative completeness of the acceptance tests developed in the Plan phase has a bearing on how many cycles are necessary.   

The cycle time for ATDD ranges the amount of time to complete a story (if they are written when the story is pulled off the iteration backlog) up to an iteration (if some acceptance tests are written prior to a story being accepted into an iteration backlog). The main participants are the product owner, business analysts, developers, testers, and other stakeholders with a stake in the story.  

Test-Driven Development

Test-Driven Development (TTDD) is the third level.  (To keep it consistent with the first two levels, it should be called Technical Test-Driven Development (TTDD), but TDD is a name in general use).  The context for the technical doneness tests are the customer/user acceptance tests.  In a tight cycle, the developer creates a technical test (Plan), implements the code to pass that test (Do), checks that the test passes along with any previous tests (Check), and then decides what tests to write next (Act).   Designing the overall approach to the implementation can be part of the Plan or the Act part.   In TDD, the tests may be revised as the implementation progresses or the design changes.  

The cycle time for TDD is in the range of minute to a few minutes.   The participants are either the developer or the developer/partner pair.  

The Act

To emphasize that there is feedback from the Act part of the cycle, here’s the diagram with the feedback loops.

Summary

We’ve shown how three levels of processes – BTDD/OBD, ATDD/BDD, and TTDD/TDD – are interrelated and how they each reflect the PDCA cycle.   In the next article, we’ll discuss how these processes relate to quality.   

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). 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.


Comments

I really like the clarity provided by this taxonomy of doneness (the principles) and their practical implementation (the actual tests). I especially like the explicit inclusion of Business Value Tests, since they are usually either just assumed or not considered at all.

I also think your cycle time comments for each level are key to helping the readers understand how they might address each level in their real-world projects. However, one thing I kept wanting see were some comments about automation -- when are tests automated vs manual.

In my mind, the elevator-speech answer is: TTDD tests are almost always automated, ATDD tests are automated when possible, and BTDD tests are almost always manual (but their may be exceptions).

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