I've just finished reading Fifty Quick Ideas to Improve User Stories by Gojko Adzic and David Evans. It's one of the best tech books I've read recently, and probably the most useful book I've ever read on writing good user stories.
The book is split in to five sections covering ideas for Creating Stories, Planning with Stories, Discussing Stories, Splitting Stories and Managing Iterative Delivery. Each idea summarises key benefits and how to make it work. The content is accessible, but the reason I liked it so much is that it's also very practical. The ideas reflect some of the politics and biases that exist in real teams and suggest good ways to work with the environment to make improvements.
The authors have published a useful mind map which acts as an outline of the book, and also a good reminder to print out and stick up on a wall. Here are a couple of my own take-aways which hopefully will give you a feel for what to expect:
When writing a story, describe the change in user behaviour that your system is trying to produce. After implementation, test to make sure that you've achieved the desired change in behaviour.
- Multi-disciplinary delivery teams have a lot of knowledge. You can unleash their creativity by telling them what you are trying to achieve rather than giving them a solution up-front. Once teams agree an approach and deliver it, we often declare victory. The authors make the point that we should plan up-front how we can test that we've achieved the behaviour change that we're looking for, and post implementation check that we actually have.
- Thinking about how to measure success helps to refine thinking about potential solutions, and like TDD makes us design in testability so that we can easily get at the right business metrics to measure success. Analysis of results can measure success but also help us to plan next steps, and iteratively build improvements through learning.
Budget instead of estimate
- I've struggled in the past with estimation. The authors suggest that in a high-trust environment rather than asking 'how long will it take?', it might be better to ask 'how much can you afford to pay for it?' and then use the answer as a constraint for a delivery team when they are coming up with potential solutions.
- Delivery teams often try to guess 'how much can you afford' as a way of choosing an 'acceptable estimate' when a reliable estimate is difficult to produce, but not always as an explicit talking point with business decision makers. Having that conversation up front seems sensible to me, and I suspect could lead to much better back and forth conversation between stakeholders around potential solutions. This may be particularly true in teams that tend to offer gold plated solutions, when for a given business requirement something quick and dirty may be more commercially sensible.
The book is available on Amazon.
Fifty Quick Ideas to Improve Tests is on the way in March which should make a nice follow-on read.
Cross posting to the Working Code blog.