Tell stories, don’t write them

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.

Key benefits

Discussions allow business representatives not only to explain what they want, but also to ensure that the delivery team members understand this correctly. Misunderstandings between different roles are a major problem with any kind of hand-over. Explaining a story face to face prevents problems from falling through knowledge gaps.

The second benefit is faster analysis. When the entire team is engaged in a discussion, functional gaps, inconsistencies and unclear requirements get discovered faster than when a single person needs to write down the details.

The most important benefit of discussions compared to hand-overs is that they produce better solutions. To be able to design good solutions, people need to know business plans and opportunities, understand the problem domain, have in-depth knowledge of technical constraints and an awareness of potential new technologies. Engaging a group of people in analysis from different perspectives helps the team benefit from shared knowledge.

How to make it work

There are several common reasons for writing down detailed stories. Most of these needs can be met without document hand-overs. Here are the most common excuses:

• When regulatory requirements or the political environment require formal sign-offs, written details serve as a record of what was approved.
• When different business stakeholders have to agree or approve plans, having something written to send out is useful. Geographically distributed organisations often have this need.
• If stories depend on the specialist knowledge of people who aren’t available to participate in story discussions, written details are a good way to transfer their knowledge.
• Where third-party dependencies or legacy systems require time-consuming analysis and investigation, involving the entire team in that would be a waste of time. Written details are a good way to capture the outcomes of the investigation.

The most common excuse for handing over documents is insisting on formal approval of scope. Without going into whether formal approval is right or wrong, if you must have it, postpone the sign-off until after story discussions. Get each story signed off as you discuss it. We’ve worked with several teams in regulated environments where due process demanded that a business sponsor approves scope. In such cases, business sponsors have signed off on specifications with examples produced as a result of story refinement and analysis discussions.

If the final scope has to be approved by several different business stakeholders, have the conversation a few days before officially starting to implement a story, and then coordinate with the stakeholders. For example, a team we worked with in an insurance company needed to get the details approved by all country managers, so they discussed stories a week ahead of the iteration. Their product owner then collected the results of the discussions, refined them into specifications, and sent them out to all business stakeholders to agree.

Effective teams with third party dependencies, or those that rely on external specialist knowledge, generally dedicate one or two people to investigate those dependencies a week or two before starting a story. The results of the investigations are a great starting point for the story analysis discussions.

Some teams analyse stories twice as a group: once a week or two ahead of the iteration to collect open questions and focus the upfront investigation, and the second time just ahead of the iteration to communicate and agree on the details. In such cases the details are often collected in the same task management tool as the stories, but teams treat them only as notes to start a discussion, not as formal requirements for sign-off.