Complex Refinement with User Story Canvas
The practice of describing requirements with user stories is widely accepted in agile community. It is also commonly used as a template for expressing the Product Backlog items. User stories describe different needs and wants of a persona who expects to get an improved experience from 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 only if developers do less reading from massive specifications and do more talking to the Product Owner. Ron Jeffries coined 3C’s principle in 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 and to be able 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 the 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 a chance that somehow developers will get it right. Confirmation of the acceptance criteria is enough for simple user stories, but not for the 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 like a story
- 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 bypassed the developer’s attention turns into re-work of existing features. 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 block: The first four units colored in blue are called a communications block. Conversation and confirmation of these units should focus Scrum team to pay more attention on the persona. Instead of putting generic user in every user story it is better to identify concrete persona (role, age, demographics, values) who should get the 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. Scrum teams rarely do this and rely on Product Owner's 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 block: Yellow units in the canvas belong the context block. Conversation here is going around user needs and confirmation describes broader context of a potential use of the 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 block: Green units in the canvas belong to the user story block. It includes User Story template, couple of solutions and acceptance criteria. A well-defined context should help a Scrum team to express the user story with a positive impact. The Product Owner will always appreciate if development team can suggest couple of solutions to chose from: ranging from the cheep and cheerful to all-inclusive.
Feasibility block: units 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 realization risks hence should be captured and agreed. 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 block: 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 User Story Canvas technique was tested online and participants agreed that to boil the ocean is not worth it. This canvas ideally fits for large and complex Product Backlog items (PBIs), but not for simple and small ones. Complete name of the technique is User Story Discussion Canvas that implies it 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 perfectly fits for refining complex and large Product Backlog items. Large but simple PBIs (this also happens) may be worth starting with User Story Splitting Patterns. When the size of a story is not too big, but still complex because of limitations, dependencies and expectations then Maxim Gaponov recommends to use the User Story Canvas only in certain parts important to discuss and confirm. Small and simple PBIs may not require comprehensive techniques for discussion and confirmation. Do you know that the 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.
User Story Canvas is applicable in broad range of different situations. Discussion of the complex stories using simple tools only 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. In order to avoid issues User Story Canvas offers a structured way for confirmation of the broader knowledge areas.