At the center of every agile eLearning development project are the User Stories that underpin that initiative. Juxtapose those stories to the countless amounts of documents that you would create to describe the solution using other methodologies – like ADDIE. That’s not to say that User Stories completely replace all the requirements and design specifications. However, they (User Stories) give solution designers and developers a unique view of the solution from a users’ perspective.
How to Frame User Stories
Think of User Stories as individual features and functionality traits that users would like to see the solution deliver. These traits will differ/depend upon:
- The role <Type of User> the user plays when interacting with the solution
- The outcome <goals or objective> they are trying to produce in that role
- The value proposition <reason or benefit> they expect from accomplishing those goals
Typically, here’s how you would frame a User Story:
In providing a list of user needs in the above format, all stakeholders have the necessary information required to make important decisions about the validity or usefulness of the story.
What Are the Benefits of User Stories
As may already be clear, User Stories are a way of defining system features and functionality in an Agile project:
- They help define the goals and objectives of an eLearning development project in a way that end-users and all stakeholders can understand. The alternative is the use of complex Requirement Definition documents, difficult-to-read (for the average user) Entity Relationship Diagrams (ERDs) and highly-technical System Specifications
- User Stories are not the exclusive domain of any single role – like the System’s Analyst or the User-Interface Developer in conventional ADDIE-driven eLearning projects. As is clear from the typical format discussed earlier, anyone on the eLearning development team can present a User Story for consideration
- Presenting course requirements in the form of User Stories helps link product owners (typically those responsible for using, managing and maintaining the courses) with the technical teams (developers, designers, testers, content creators)
- The use of User Stories offers a unique way for agile eLearning development teams to manage product features throughout their lifecycle – from high-level conception through execution at the lowest-level
And while these are specific benefits that the stories themselves provide to the project, the process of crafting, refining and presenting User Stories also serves an important function in the lifecycle of eLearning development projects. It (the process) fosters group collaboration and collective ownership of the final course.
Unique Ways to Write and Present User Stories
eLearning course sponsors usually craft User Stories during brainstorming sessions. To make these sessions effective, all stakeholders in the eLearning initiative must attend. Moderators, with major inputs from participants, create and present the stories using various tools, including softboards, whiteboards and brainstorming “idea walls”. The most commonly used medium to write User Stories is the familiar sticky note.
To make User Stories actionable:
- You must write them in the format specified earlier
- Craft them using short, clear and concise words – NOT rambling statements/paragraphs
- Where possible, highlight key components of each statement to draw attention to significant parts of the story (Who is requesting it? Why is it needed? What value will it provide for the course?)
Presentation of User Stories, during brainstorming sessions, is also key to using stories effectively during eLearning development projects.
- A typical session might start out by “throwing everything at the story wall” – regardless of who initiates a story or what technical or functional need it serves
- Next, moderators will lead the agile team through a detailed debate of each story. During these deliberations, the team examines key aspects of the story to determine:
- How critical the story is for the project
- Whether the story can be modified to deliver a bigger bang for the same amount of time and effort
- If it makes more sense to combine aspects of the story with others on the board
- When (which Sprint) it makes the most sense to develop the story
This process results in a rearranged storyboard that makes it easier for everyone to follow how the overall course development will unfold. Moderators may then group, rank and present stories by order of Role (e.g. Student Administrator) or other characteristics (priority). Brainstorming is an iterative process during which a story may evolve through several versions as a result of team deliberations.
How to Make User Stories Work
One of the benefits of following an Agile approach is that each development effort – a Sprint – results in a fully functional and implementable component of the final course. To make User Stories work therefore, you must develop them is a way that the entirety of their scope fits in a single Sprint.
If for some reason, technical or logistical, a single story can not be delivered in a single Sprint, you must work with the team to re-define the story so the essence of what’s asked is spread over more than one Sprint.
How you prioritize and re-arrange User Stories on the storyboard also influences their impact on the overall eLearning development project. In the above graphic, we’ve color-coded Student Administrator stories using yellow sticky notes, while using lime/green ones to depict Course Administrator stories. This visual depiction helps when planning Sprints.
If we look back at our earlier example, in Writing and Presenting User Stories above, the Course Administrator had first made his/her request for “printing, viewing and downloading” course enrollment data. However, upon further discussion, the team re-organized those thoughts and re-prioritized the Course Administrator stories. As a result, the logical flow will be to first define the Course Catalog and then build features to “print, view or download” related information.
The physical mechanism for defining and prioritizing User Stories can also play a role in how effectively User Stories are used during the development process. You could rely on a flat surface – such as a wall on your office or whiteboards in a conference room.
Alternatively, you could also use specialized software, such as Stories on Board, Miro, Feature Map or Note.Ly (used by us to create our sample stories). Regardless of the method or tools used, the process for creating and using User Stories remains the same.
Want to know more about writing effective user stories and the Agile process in general? Get my Agile ELearning Development book and start developing your courses the Agile way!
Leave a Reply