There are many approaches that work well when elaborating stories and the team should decide on the approach that works best for them.
I have broken some approaches into the following categories for the purpose of explaination:
- Code and see – Developers build from their understanding of the system together with frequent questions and demonstrations;
- Decomposition – Breaking stories into more detail. Frequently this means using acceptance tests or tasks, but can include technical stories or use cases;
- Abstact to concrete – Abstracting the meaning of a story through a structured conversation and then defining the concrete alements of the story;
- Modelling – Creating a model to represent the story and then using the model for development; and
- Comparison tables – Listing stories on one axis of a table and loisting the technical or “quality” components of the story on the other axis and then cross-referencing. For example comparing stories to non-functional requirements.
I have listed some of these approaches below and written articles on the remainder. You can also find a PDF version of these articles on the Software Education Resources page.
Code and see
There is a misunderstanding in some circles about agile approaches in general and the use of stories in particular. People seem to believe that if we are using stories then we give nothing else to developers and they have to guess the details of what we want. In fact most teams give the developer a lot more information than what is contained on a story card.
However, there are times when the best approach to have a conversation with the developer (and tester and the rest of the gang) and then let them put something together. Of course, this does not meant that they only get one shot to get things done.
Rather it means that the developer starts work and then comes back with both questions and frequent demonstrations of what the emerging solution looks like.
This can be very effective with a team that sits close to their customers, has experience in customer needs and also
Tips and things to watch out for
In this approach, it is critical that feedback is constant and that the developer has direct contact with someone who will make decisions about the final product.
It is also important that the developer, tester, business stakeholder and any other team members see themselves as equals. If the developer is scared of the business representative or worse, contemptuous of the business representative’s views then this approach will lead to trouble.
This approach can work very well when creating a new user experience, though the solution is normally demonstrated on paper or in sketch form while the system is emerging. The key to success is that there is a low cost of being wrong and doing rework while building the product.
The approach can also work well when reverse engineering a solution (eg replacing an aging system) as long as the developer and customer are challenging each other’s thinking and confirming the solution along the way.
The major risk with this approach is that the developer will build an ad hoc solution that does not integrate into the broader system roadmap. There is also a risk that the developer will build a system “like an egg” – seeming solid on the outside but fragile and easy to break … and then very hard to put back together.
More detailed approaches
Most teams decompose stories into smaller units in order to build them. Generally this is done as a team though in some agile teams a small group within the team look at the story and break it down.
The most common approaches are to break down stories by acceptance tests or to convert them into tasks. However some teams break simply break the stories into what I call “technical stories” – this could actually mean they create use cases, they create functional/non-functional/technical requirements or that they simply write down notes to remind themselves of what to do.
Some teams merge stories into models first and then build the system from the model.
Beyond these common techniques there are two approaches that I like to use that are called
Both of these approaches are really just structures for a conversation that then leads to either decomposing stories using the techniques mentioned above, creating a model or using the “code and see” approach.
Each technique has merit in some situations and each has some limitations or risks. So I hope to provide a little more detail on each of these over the coming weeks. Let me know what you think and also if you have better (or different) approaches that work well.
James King 