Scenarios, like requirements, can often be too large to work with effectively. In this episode we'll examine why this is a problem, and some example of how we can deal with it.
Keep Scenarios Small
Business automation is all about taking general purpose computers and making them do specific things. We term these things "behaviors" because that's the best way to understand them: cause and effect. These behaviors must deliver value commensurate with the effort it takes to create them, or they represent some degree of waste. We use stakeholder requirements to align ourselves with business value.
But a given requirement may contain many behaviors, and each behavior may have any number of variations. In acceptance testing we reflect each behavior, and each variation, in a scenario that can be tested. But scenarios have to be the right size. Specifically, if they are too large this will cause multiple problems that can seriously damage the development effort.
Overly large scenarios:
- Cannot fit into an iteration of work.
- Require swarming to complete them, which can disrupt or prevent other valuable work.
- Are more complex and time consuming to define.
- Involve too many stakeholders for effective collaboration.
- Create large errors in estimation of the time and effort required to complete them.
- Give vague indication of progress toward the valuable goal.
- Are hard to validate with any degree of confidence.
Because of these factors, the team must know how to effectively break large scenarios into smaller ones that can be scheduled and tracked. How this is done depends on the reason that the scenario is too large in the first place, and since these reasons vary so must the techniques used to break them down.
Here are some examples:
Complex business rules can be broken down into the smaller rules that comprise them. Then, each rule can be specified, tested, and developed in its own scenario. Once all the smaller rules are proven to be correct, a single integration test can prove they work together properly.
A scenario can be broken down by the stakeholders that are interested in it. If there are too many to be able to schedule a meeting that will engage them all, then you can use the specific domain knowledge sub-groups possess to break it up.
Scenarios, like requirements, live in a structure. Most project management tools establish terms for the layers in this structure, like Product, Epic, Feature, Story, and so forth. If scenarios are broken down along these same lines, then the ones near the bottom of the structure will tend to be small enough to effectively engage with.
Highly detailed requirements can be broken down into the incremental steps needed to accomplish them. This not only makes them easier to schedule, track, and develop, but also easier to debug because they can be tested in a more fine-grained way.
The different layers in a system's architecture such as UI, Mid-Tier, Persistence, or whatever layers are appropriate for a given organization and its work also provide a way to break down a large scenario by looking at it from the perspectives of these different layers. This also results in a much more flexible, reusable, and maintainable test architecture.
To become effective in each technique requires training, of course, and it's a major part of the ATDD course available here at PMI. In the scenario-breakdown section of the course, each technique is demonstrated on an appropriate scenario, and then hands-on exercises are used to make the knowledge concrete. Students leave with a very effective toolkit for solving the problem of scenarios that are too large.
Information on our ATDD course:
https://www.pmi.org/business-solutions/agile-training/technical-solutions/acceptance-test-driven-development