Great solutions don’t always start with great ideas. One of the mistakes many of us make is keeping our half-developed ideas to ourselves, and trying to present the perfect solution before we dare to share with others.
When we share ideas early in a process, we take a risk that they will be judged in their unrefined state or worse still, dismissed before their potential can be explored. To stop this happening, we need to use a shared language to communicate ideas in ways that stakeholders from diverse backgrounds can understand and use to make further decisions.
A ‘user story’ is a great tool to communicate ideas and requirements in a structured way. Originating from the agile software development approach, user stories were used to break down language barriers between users and developers by focusing on what the outcome should look like for the user. Since then user stories have become a popular tool for documenting ideas and requirements across disciplines that need to evolve and adapt to continuous change.
What is a user story?
As a < type of user >, I want < some goal > so that < some reason >.
Asking the WHO, WHAT and WHY, a user story is a simple sentence in an active voice describing a functionality from a user’s perspective.
This simple structure helps to communicate clearly, avoid misunderstandings and concentrate on the goal of the user and the expected benefit. Deliberately, user stories do not talk about the HOW to avoid jumping to conclusions or looking for solutions too early.
How do we work with user stories?
Write your user story down
Follow the structure and keep it simple. Working with index cards and their physical borders gives you a good frame for the complexity and length of a story.
Make it visible and accessible
Dedicate an area, a wall or board, as the place to put your user stories. Choose an area where people walk by and where you can discuss and exchange ideas. Note: Your story will ideally spark other stories, so let the area grow into a collection and incubator of good ideas.
Get input from others
Now that the story is out in the open, make sure you engage in conversations with stakeholders (customers, users, marketing, IT, HR – the more diverse the better). This will help to refine the story and its context. Everybody involved can benefit from a better understanding of each other’s needs and motivators, which will ultimately increase the chance of hitting the right spot with an idea.
Adapt and add detail
Stay agile with your story and let it change and evolve based on the insights you pick up. Over time, the story will get more detailed and specific. To avoid cluttering the story, the details are captured in ‘acceptance criteria’. The simplest way to explain acceptance criteria is that they are items on a checklist that mark the boundaries and parameters for a story. Later, when working on a solution, each item can act as a test case. The story is fulfilled when each acceptance criterion can be ticked.
Going back to the example with index cards for user stories, the acceptance criteria go on the back of the card. This way, the story stays simple and easy to understand but the specifics are in close proximity.
Continue until everybody agrees
This iterative process of discussing and specifying the details continues until the involved stakeholders find a consensus, confirm that the implemented story will add value to the user and agree there is enough detail to start looking into solutions – the HOW.
Look for a solution
When it is clear what the outcome should look like, the user story and the acceptance criteria empower the implementing team to find the best (technical) solution. It can be hard to wait a long time before you start looking for solutions, but this way you make sure you find a solution for a great need, and not a great solution that doesn’t solve the problem.
User stories in action: Developing a virtual classroom plugin for Moodle
In 2017, Navitas Learning & Teaching Services worked together with the Careers & Industry (C&I) division during the transition to their new virtual classroom tool, Zoom. Based on qualitative interviews, 10 different roles were identified and 107 user stories gathered.
In this case, user stories helped us to understand what students, teachers, managers and administrators needed and allowed the implementation of a Zoom Moodle plugin that meets Navitas’ needs. The latest version of this Navitas Zoom Moodle plugin will be part of Navitas Core Moodle 2018 and available to Navitas businesses globally.
Have you used user stories to resolve a learning and teaching challenge? Get in touch and share your story! To continue the conversation, contact Andrea Scheuringer, or share your thoughts and ideas via Yammer, Twitter or LinkedIn.