The practice of describing requirements with user stories is widely accepted in agile community. It is also commonly used as the template for expressing the Product Backlog items. User stories describe different needs and wants of a persona who expect to get a better experience with products and services comparing to the current situation. User stories motivate developers to solving user problems, not just performing technical tasks.
Key Challenges with User Stories
User Story was created as a tool to improve understanding of requirements once developers do less reading from massive specifications and do more talking to Product Owner. Ron Jeffries formulated 3C’s principle i order to reinforce the purpose of User Story.
- Card: User Story should be concisely written on the card, following the template: AS A <user> I WANT <describe need or want> SO THAT <describe a benefit>
- Conversation: Developers, exploring the card, communicate with the Product Owner, in order to gain knowledge about the business domain. They explore the context, to offer valuable ideas for implementation
- Confirmation: The most important details that were revealed in the conversation should be documented as confirmation between development team members and Product Owner
The principles look simple on a surface, but difficult to implement. The card that doesn’t express user problem statement, conversation that doesn’t have structure, confirmation that doesn’t properly documented – only a tip of the user story anti-pattern iceberg. Usually conversation between developers and Product Owner goes around acceptance criteria just to negotiate scope of requirements for one user story, but knowledge and context are not conveyed in the same structured way, so here we rely on chance that somehow developers will get it right. Confirmation of the acceptance criteria only is enough for simple user stories, but not for complex ones.
Maxim Gaponov, author of User Story Canvas, thoroughly researched why analysis of complex user stories often leads to a negative result, and pointed out the following reasons:
- User story is used to describe all knowledge about the product, even if some parts of the knowledge doesn’t sound as a story from user
- It is not clear what to include
- When making them common then we are losing control
- When making them detailed then we only maintain it
- Communication gaps lead to re-work
- Lack of standard description
- Loss of focus in discussions
Knowledge About the Product
When we want to build good knowledge base out of a user story then we need to talk about personas, stakeholder needs, context of the product usage, business domain, constraints, data availability, etc. Many important aspects can simply bypass the developer’s attention which turns into re-work of existing features, instead of creating the new ones. User Story Canvas can help us to fix these problems by focusing Scrum team to discuss more important aspects with the Product Owner than just acceptance criteria.
How to Fill a User Story Canvas
The User Story Canvas has a clear structure and suggests certain order of discussion.
Communications Unit: The first steps colored in blue are called a communications unit. Conversation and confirmation of this unit should focus Scrum team to pay more attention on the Persona. Instead of putting generic user in every user story we should identify concrete persona (role, age, demographics, values) who should get most benefits from realization of the suggested user story. Secondly, the Scrum Team identifies SMEs who can consult the team when they discover knowledge gaps in the business domain.
Scrum teams rarely do this and rely on Product Owner opinion hence making him as bottleneck. How about stakeholders and customers? What are theirs expectations, what kind of questions they can ask when attending Sprint Review? I still facing common problem when implementing according to acceptance criteria doesn’t guarantee stakeholder’s satisfaction.
Context Unit: Yellow steps in the canvas belong the context unit. Conversation of this unit is going around user needs and confirmation describes broader context of the potential use of new functionality. It’s also useful to confirm what is wrong with current user experience. Implementing acceptance criteria delivers some outputs, but delivering improved user experience contributes to the business outcomes.
User Story Unit: Green steps in the canvas is called User Story unit. It includes User Story template, couple of solutions and acceptance criteria. A well-defined context should help express the user story with a positive impact on the user. I often see that Product Owner expects the development team to suggest couple of solutions to chose from: ranging from cheep and cheerful to all-inclusive
Feasibility Unit: steps colored in red add all sorts of technical knowledge about the product. Scrum team should discuss and confirm technical limitations in terms of architecture, API, supported technologies, available data, etc. Technology complexity can pose some risks thus should be captured and agreed as well. Very often I see that adding another feature can potentially require adding more nodes to the cluster. Increasing amount of data may require re-architecture of the existing solution. Clearly identify all dependencies if some required data isn’t available in the DB or via external API.
Outcome Unit: The last two steps colored in purple includes feedback from users outcomes in terms of customer satisfaction. Development team can believe that a user story completed when it meets acceptance criteria and accepted by the Product Owner. But this is not quite true. A story is the story from user perspective, therefore feedback should be collected from users. You need to understand how to automate collection of usage statistics. Maybe developers should integrate the story with Google Analytics, or develop custom solution for tracking real usage of new functionality.
Using User Story Canvas
The participants of the last meetup, who helped to test online usage of the User Story Canvas, agreed that boil the ocean is not worth it. This canvas ideal for large and complex Product Backlog items (PBIs), but not for simple and small ones. User Story Discussion Canvas is the full name of the tool that implies the tool will be used to facilitate the discussion of the PBIs. It’s an ideal tool for regular product backlog refinement meetings, where you would start the discussion with a preliminary assessment of the size and complexity of the PBI in order to find the right tool for discussion.
User Story Discussion Canvas fits perfectly while refining complex and big product backlog items. Big but not complex PBIs (this also happens) may be worth starting with User Story Splitting Patterns. It happens that the size of the story is not big, but complex because of limitations, dependencies and expectations. In this case, Maxim Gaponov recommends to fill in only relevant units of User Story Canvas, only areas that are important to discuss and confirm. Small and simple PBIs may not require comprehensive techniques for discussion and confirmation. Do you know that User Story is not mandatory in Scrum at all?
Online Facilitation of the User Story Canvas
If you are in a distributed team and run product backlog refinement meetings remotely the User Story Canvas works excellent. To facilitate it effectively you can try following:
- Prepare a board in Mural or Miro. Add to the board a high-resolution canvas
- Start a meeting at Zoom ensuring that User Story Canvas will be perceived positively by the team. Remember recommendation when to use User Story Canvas for discussion
- The process consists of five steps of 10 minutes. You’ll need 30 to 90 minutes to fill up the canvas, depending on the complexity of the story.
- To discuss each unit of the canvas, the Scrum Master or meeting facilitator sets the timer and opens the conference room for 10 minutes. When time is up, Scrum Master closes the room, gathers feedback, answers questions, and reopens the room for another 10 minutes to discuss the next block.
Thanks to the participants of the meetup we could confirm the hypothesis about the suitability of this tool for distributed teams.
User Story Canvas is applicable in broad range of different situations. Discussion of complex stories with simple tools leads to the loss of an important knowledge and, as a result, we get many problems with implementation, delivery, non-compliance and all other sorts of conflicts.
- Essential XP: Card, Conversation, Confirmation by Ron Jeffries
- Start with design — Stanford d.school
- Pragmatic Personas: Putting the User back in User Stories
- INVEST in Good Stories, and SMART Tasks – XP123
- Twenty Ways to Split Stories
Stay OnLine! Subscribe to my blog!