User Stories Don’t Deliver Business Value
User stories tend to focus on the user not on the business value. I think it’s largely to do with the popular “As a <insert type of user> I want to <insert thing to do here> so that <insert reason here>” format.
This more formal wording of user stories takes longer to think about and write down and I’ve found it can slow down story writing workshops and hold up the creative process.
Remember that User Stories are merely the promise of a future conversation
1. Use 5×3 cards as max size
2. Get the customer writing the story
3. Try to write, in as few words as you can, a title that the customer will remember what is needed
4. Capture the business value as the story title
5. Avoid any implementation details (e.g. words like screen, page, button and anything else that is a thing that will get implemented in a system)
The trick is to defer discussing the implementation details of a story until the last responsible moment. Ideally this will be at the point that someone is actually able to work on the story. In general this works out fine but there are times when you’ll need a little more upfront thought. One example of this is when you’re integrating with things (software/hardware) outside of the teams control. Often a little more upfront work and coordination is required.
As stories hit the backlog quickly markup the ones that require more upfront thinking (look for dependencies, technical risk etc) and review the backlog at least weekly to make sure you’re on top of getting these stories in play in a timely manner.
Lean/Kanban people often talk about focussing on business value – in fact I’m one of those very people and generally this is the right thing to do. However there are times (like those described above) when technical concerns need to be balanced against business value.