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):
- 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.
- 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 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
Links to this post
But that's another story
What is a user story?A user story is a distinct unit of customer-visible functionality that does not have to represent business value but must represent progress to the customer. A user story describes some functionality and is both meaningful to the customer and to the developers. A user story comprises the following elements:
1. Card: A written description of the functionality used for adaptively planning incremental development
2. Conversation: Discussions facilitating a drill-down into the details of the functionality required
3. Confirmation: Acceptance tests capturing the details and used to determine when a user story is complete
While the card contains the description of a user story, the details are derived through conversation and recorded in the confirmation. Think of user stories as representing a conversation that has occurred between the customer and the developers, as opposed to documenting customer requirements.
How long should a user story take to develop and test?
A user story should take about between two days and two weeks to complete.
Capturing the detailsIt's difficult to start developing a user story without more detail. The developers should discuss the details of a user story with the customer at the point when the details become important, adding notes to the user story as appropriate. What is important here is the conversation between the customer and developers, and not the annotated user story. User stories are not contractual obligations. Agreements between the customer and developers are documented by acceptance tests, which demonstrate that a user story has been developed correctly. In some situations it may make more sense to include details as new user stories. It's better to have more user stories than to have a few user stories representing greater functionality. User stories that are too large are called epics and the customer should split them into two or more smaller user stories.
Acceptance testsThe expectations of the customer are recorded as acceptance tests. The test descriptions convey additional information about the user story, which helps developers to recognise when they are done. Acceptance tests should be written as early as possible so that the customer's assumptions and expectations are communicated to the developers early.
Who writes the user stories and acceptance tests?The customer writes the user stories and acceptance tests for the following reasons:
1. The customer is in the best position to describe the desired functionality
2. Each story must be written in the language of the business so that the customer can prioritise the user stories by business value and select the user stories for each sprint.
The developers and testers can assist the customer but the responsibility for writing stories must reside with the customer. If testers are present, they should be responsible for developing automated acceptance tests, otherwise developers should do it.
Compulsory readingMike Cohn's book
User Stories Applied For Agile Software DevelopmentTags:
agile,
user stories
Links to this post
What makes a good software developer?
Yesterday i was asked "what do you think makes a good software developer?" I think my answer surprised the person asking the question. It went something like this:
"Fundamentally a good developer has a high proficiency in programming with an innate ability to create well-crafted code - code that is simple, extensible, optimized and robust. He has fulfilled other roles in the project lifecycle, experiencing development from other perspectives - analysis (especially right up at the business end), architecture, configuration/build management, non-functional and user acceptance testing, operational roll-out, etc. He harnesses these experiences and distils knowledge, coupling it to his core programming skills. "
Fairly standard stuff, so far.
"Just as importantly - and this is where a lot of developers fall short - a good developer posesses excellent soft skills - communication; time management; awareness; tactical and strategic thinking (detailed planning with an eye on the big picture); an ability to identify risk, weigh-up options and make decisions quickly; objectivity and pragmatism. He also has the courage of his convictions. A good software developer has the ability to 'think' in different dimensions."
I believe an ordinary developer with poor soft skills can survive as a programmer. You'll find him in a cubicle. An
agile developer won't get out of the starting blocks without strong soft skills. An
agile developer thinks in different dimensions and is conscious of his relationships with others. He understands his contribution to the team and the contribution of others. An
agile developer lives by the values of
agile and is guided by the principles in everything he does.
An
agile team can self-organise because every
agile developer is a unification of at least the following roles: software craftsman, tester, team leader and project manager.
Tags:
software developer
Links to this post
What agile is about
Companies need to understand that
agile is an attitude that must pervade the social, cultural and political dimensions of an organisation. Choosing to go
agile is a commitment to an effort. Adopting
agile is a process of change which emphasises collaboration, empowerment, respect and humility, courage, honesty and trust. Ultimately
agile is all about people.
I have no doubt that there are definite benefits in adopting just the development practices of agile, e.g. test-driven development and continuous integration to name two. Indeed, there will be some benefit when only a handful of agile's development practices are adopted. But so much more can be achieved when people liberate themselves from the shackles of traditional software development approaches and live by the values of agile, rely on their knowledge, experience and instinct and be guided by the principles of agile.
The full benefit of agile may only be realised when an organisation's culture is an outward demonstration of the values of
agile.
Tags:
agile
Links to this post
