Slicing the cake

There are two techniques for disaggregating user stories into engineering tasks. The first slices a user story vertically and the second, horizontally. I favour vertical slicing because the development approach enables the user story to evolve, demonstrably, in front of the customer.

Vertically slicing user stories

Effectively, this development approach builds up the user story through successive refinements. Each refinement delivers a journey from front to back-end (in simplified terms, this includes some JSP(s), some business logic and some data access), 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 user story may produce the following engineering tasks (amongst others):

1. Display a credit card form with pre-populated credit card details that cannot be edited, and a 'buy now' button which simulates the purchase of the shopping basket by displaying simple dummy receipt data.


2. 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.


3. 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).


4. 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 ultimate functionality represented by the user story can be developed in vertical increments comprising working UI. I prefer tests not to be explicitly listed as engineering tasks. Instead JUnit tests and FIT acceptance tests are implicit in the engineering tasks and are necessary to demonstrate completeness of those tasks. The tests are refactored in line with any refactoring of the functional code.

Vertically slicing user stories enables the customer to play regularly with the user story functionality as it emerges through its UI and to provide rapid feedback, which consequently steers development effort. The customer can quickly recognise when refinements are not justified in terms of their return on investment. Acceptance tests can be developed in parallel with the user 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 user 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 engineering tasks that associate directly to the architectural layers of the system or to resource specialities.

The main drawbacks of this approach are that it may be some time before demonstrable UI for the user story is made available to 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.


Tags: agile, user stories, adaptive planning

posted by Simon Baker @ permalink
blinklist : del.icio.us : digg : furl : simpy : spurl : reddit