185 pages, published in 2014

User stories are often misunderstood as lightweight requirements, given by the business stakeholders to the delivery team. This misunderstanding leads to stories being collected in a task management tool, with a ton of detail written down by business representatives. Except in the very rare case where the business representative is also a technical expert and has a great vision for the product, this division of work prevents organisations from reaping the benefits of user stories. To make things crystal clear, if a team passively receives documents in a hand- over, regardless of what they are called and whether they are on paper, in a wiki or in a ticketing system, that’s not really working with user stories. Organisations with such a process won’t get the full benefits of iterative delivery. User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions. When domain and technical knowledge is spread among different people, a discussion between business stakeholders and delivery teams often leads to good questions, options and product ideas. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made. Effective discussions about user needs, requirements and solutions become critically important with short delivery phases, because there just isn’t enough time for anyone to sit down and document everything. Of course, even with longer delivery phases documenting everything rarely works, but people often maintain a pretence of doing it. With delivery phases measured in weeks or days, there isn’t enough time to even pretend. When a single person is writing and documenting detailed stories, the entire burden of analysis, understanding and coordination falls on that person. This is not sustainable with a rapid pace of change, and it creates an unnecessary bottleneck. In essence, the entire pipeline moves at the speed of that one person, and she is always too busy. Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations, and don’t waste too much time nailing down the details upfront. Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.

Gojko Adzic and David Evans