Slicing the cake
There are two techniques for disaggregating stories into tasks. The first slices a story vertically and the second, horizontally. I favor vertical slicing because the development approach enables the story to evolve, demonstrably in front of the customer.
Vertically slicing user stories
Effectively, this development approach builds up the story through successive refinements. Each refinement delivers a journey from front to back-end, building upon the previous refinement and enriching the overall functionality provided. As an example, consider the user story:
“A user can pay for the items in her shopping basket with a credit card”
Slicing vertically through this story may produce the following tasks (amongst others):
- Display a credit card form with pre-populated credit card details that cannot be edited, and a ‘buy now’ button that purchases the shopping basket by displaying simple dummy receipt data.
- Modify the credit card form to accept user-input and to perform validation of the credit card details – valid credit card number for selected card type, expiry date after start date, issue number present for Switch.
- Modify the ‘buy now’ business logic to simulate a credit card transaction using the validated user-input card details (perhaps using a mocked payment processor).
- Hook-up ‘buy now’ business logic to real payment processor to perform round-trip test transactions to payment service provider.
This example simplifies the interaction between the payment processor and the shopping basket but it does demonstrate how the final functionality represented by the story can be developed in vertical increments comprising working user interface. I prefer tests not to be explicitly listed as tasks. Instead JUnit tests and FIT acceptance tests are implicit in the tasks and are necessary to demonstrate completeness of those tasks. The tests are refactored in line with the functional code.
Vertically slicing stories enables the customer to play regularly with the story functionality as it emerges through its user interface and to provide rapid feedback, which consequently steers development effort. The customer can quickly recognize when refinements are not justified by their return on investment. Acceptance tests can be developed in parallel with the story with their pass/fail status providing a constant indication of progress. This test strategy can also help remove big-bang test effort at the end of an iteration. Both the customer and testers are engaged from the start of the iteration. Developing stories in vertical slices is much easier when the developers are generalists or are able to pair-program.
Horizontally slicing user stories
This development approach creates tasks that associate directly with the architectural layers of the system or resource specialties.
The main drawbacks of this approach are that it may be some time before demonstrable user interface for the story can be viewed by the customer, consequently delaying valuable feedback, and that it’s not possible to see FIT acceptance tests running as development progresses. This contributes to big-bang testing at the end of the iteration.