User stories foster conversations and learning

User stories foster conversations and learning

User stories foster conversations and learning. They also help teams work together.  However, it isn’t always easy. There are five typical problems that affect the effectiveness of user stories.  These problems generally reflect difficulty in the execution rather than systemic problems with the concept of user stories. Problems include:

  1. Technical stories. Most normal user stories include the technical components needed to deliver the benefit stated in the story. Purely technical stories may or may not deliver a benefit that a Product Owner can prioritize.  For example, how would you demonstrate the impact of a refactoring story or a story to upgrade Visual Source Safe (VSS), unless they are part of a story tied to delivering business value?
  2. Stories are still just words. Part of the rational for embracing Agile and user stories reflects a mechanism to avoid relying solely on a requirement document.  Words mean different things to different people.  As we noted earlier in the week, user stories are all about the conversations. However until we convert our memories and notes into a design and then into tested and reviewed code, we still have room for interpretation.  A solution for this shortcoming is to take notes during conversations and to keep your iterations short to so that you can generate feedback often.
  3. A generic persona is hard to engage. Personas by definition are a metaphor for a group of users.  Using overly generic user personas in user stories makes it hard  to talk to a broad enough of people in the group to ensure you are going to deliver what is really needed. Similarly, using the Product Owner or developer as the persona in a user story tends to happen when teams are avoiding the hard work of identifying the real users of the application.
  4. Not identifying the benefit of a story.  Simply put, if you can’t identify the benefit of a user story how can the story be prioritized?  If identification is a problem define a spike (a specific time box set aside to do research) to do the research to understand the benefit. And if the story does not have a demonstrable value, do not do it.
  5. Stories without acceptance criteria.  Acceptance criteria are an integral part of the definition of a user story.  Acceptance criteria represent conditions that will need to be satisfied and can be tested before declaring the story “done.” This might be the worst of the problems and can set off a cascade of errors: identifying the wrong development tasks, wrong estimation or a failed story. Not defining acceptance criteria is a pure failure of discipline.  Techniques like the Three Amigos (leveraging a Business Analyst, Product Owner or SME and Technical Lead to define the acceptance criteria before prioritization and sprint planning) are an effective means of creating high value acceptance criteria.

When teams have implemented user stories poorly, the problems generally observed reflect poor technique rather than intrinsic problems with user stories. Requirements have historically been a source of some of greatest project failures and the most costly defects. Agile has helped many teams develop better requirements through direct conversation with business users, generating feedback though testing to ensure that the work is done and then demonstrating that work to a wider pool of stakeholders. Losing the discipline of developing complete user stories is asking to continue the same requirements problems that Agile is trying to solve.

Advertisements