Avoid rework by having a clear definition of done before implementation begins. Streamline approvals by regularly demonstrating agreed behaviours.
Rework increases the time to deliver working software.
Rework occurs when misunderstandings, miscommunication or ignorance result in faulty assumptions and incorrect system behaviour.
Remove ambiguity by ensuring that the entire team reaches consensus on how the system should behave before you write a line of code.
Acceptance test-driven development is the practise of creating a shared understanding of your product requirements using specifications in plain English.
This later can be turned into automated tests using tools such as Cucumber. This form of planning ensures your developers are building the right thing, similar to how unit tests ensure you are building the thing right.
To ensure that you are building the right thing – the thing your end users need – you need to verify your work against a set of criteria.
The criteria for acceptance testing is defined in collaboration with domain experts and key stakeholders. This ensures you and your development team don’t waste time creating features that do not solve the customers’ needs.
A thoughtful list of acceptance test criteria is an important factor in preventing overproduction or gold plating.
This action plan is not about automation – that can be done in the future. The purpose of this action plan is to discover a clear definition of the problem and your end goal, to reduce your feedback loops and rework.
Having the conversations with your users earlier, and more regularly, reduces the risk of building the wrong thing, under delivering or over producing.
Hold one or more discovery sessions to form a detailed understanding of what you are trying to build.
Ensure the correct roles are present. Your user representative, or product owner, understands what you need to build and why.
The developer role, especially the person who is implementing the feature, needs to understand how to implement the feature requirements in your system.
The tester role helps to uncover gaps in understanding by asking “what if...” questions.
Ensure you write everything down and document what was said in each session. The goal of a discovery session, such as example mapping, is to:
Reach a common understanding of what you need to build, both your scope of work and a shared definition of done.
Tackle misunderstanding and ambiguity by capturing concrete examples to illustrate your requirements.
Uncover gaps – the unknown unknowns – by capturing questions you need to answer before starting development.
Until you have captured all the end user requirements, verified your assumptions, answered all outstanding questions (or explicitly limited the scope to exclude them), and ensured the development team are clear on what it is they are trying to build, you are still in discovery.
Use your discovery process to uncover hidden complexity. A story, or use case, may seem trivial on the surface but once discussed, the true complexity is unearthed. This helps break down the scope to deliver the most valuable parts now and defer other aspects until later.
Before starting development, it’s important to formalise the outputs of your discovery session, and gain agreement from your stakeholder(s). This is your opportunity to play back what you learned during discovery and ask “Is this what you meant?” It forms the scope of the project to prevent scope creep that leads to delays and project overruns.
Turn each example captured during your discovery session into a formal acceptance test using a specification language such as gherkin and gain approval from your business stakeholders.
This now forms part of your definition of done. If you can demonstrate that these acceptance tests pass, then your software should be ready for release.
Important: Following this plan does not mean the requirements are set in stone. It is intended to avoid rework caused by misunderstanding and help guide the development. If you find that your requirements change often, this step is crucial.
Break down delivery into smaller increments so that you can demonstrate progress more frequently, confirm current understanding of the requirements, and adapt as necessary.
Each acceptance test should demonstrate an incremental piece of value to be delivered when demonstrated.
Once the tests have been written, it’s time to implement the new feature according to the feature requirements gathered in the discovery phase.
Demonstrate progress as early and as often as possible to the participants of the discovery session. Ideally, show demos in a production-like environment.
Where possible, implement functionality one acceptance test at a time. Demonstrate each one to your discovery session participants. This provides the earliest opportunity for feedback and course correction, where necessary.
If you are unable to give live demos for any reason, consider making screen recordings to demonstrate each acceptance test and share those with the team and discovery session participants to show progress and gather feedback.
Perform exploratory testing during the development process to uncover any missing assumptions or limitations resulting in defects. Incorporate the results of your exploratory testing into your acceptance test criteria and update your definition of done.
Once the feature meets all the specified acceptance criteria, a formal user acceptance meeting with the key stakeholders should be a formality.
They should have already seen the work and had the opportunity to comment. This can take the form of a showcase, where acceptance tests are demonstrated one by one in a production-like environment and approval is granted at the end.
Driving Development with Tests: ATDD and TDD
Test Driven Development: By Example, by Kent Beck
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development by Markus Gärtner