Poster image for this article
Source: Daria Nepriakhina on Unsplash.com

Activating User Stories

Share this post:

Projects at the CTL, especially software projects, often start with a discovery phase that involves envisioning how a tool we’re building will be used. We write out user stories with great care and effort, outlining particular features and functionalities. Several of my current projects are in the discovery phase and others are further along—but the question of how we look back at and activate written user stories persists. There’s often a swirl of conversations, notes and proposed features that encircle and sometimes entangle these user stories, making it difficult to keep track of priorities and specific tasks along the road to launch. Sometimes talking about what we want to build and how to build it can lead to a quagmire of discussion that lacks action. I’ve definitely felt this concern before and I’d like to share a few tips for activating the user stories we write.

The Process

As a team, start by thinking through the different types of users that will be using the software. These can be written as user personas. Typically personas have distinct components, so it’s helpful to ask a set of questions when envisioning a persona. What are their goals? What might they hope to gain from what we’re building? What’s their background (it might be useful to include age and gender)? What are their behaviors and teaching or learning habits? What are their pain points—the frustrations this person might have with their current toolset? And possibly the most important—what are their needs?

Once user personas are in place, it’s time to write user stories. It’s helpful to keep the format in mind. Follow a template when writing user stories. This helps standardize the process and makes it easier to extract important information later on in the development process. Pay attention to the acceptance criteria section—this doesn’t always have to be written at the same time as the user story, but it’s very important to define what it means for the user story to be done or implemented.

A diagram summarizing the format of a user story and and its acceptance criteria.

After several user stories have been written and the list is growing, it’s crucial to practice user story mapping. This means grouping user stories by function and defining the broad categories they fit into with respect to the software that is being built. It’s important here to map user stories to specific steps in a documented implementation plan. Additionally, we should be going a few steps further and breaking each user story down into discrete tasks.

Activating the User Stories

The process above outlines a structure for the format and documentation of user stories. But what about the persistent duty of ensuring our work engages those user stories? Check out the following tips for user story activation:

  • Reference them early and often—the most crucial practice that will help activate user stories is referring back to them often!
  • Ask the team questions like “how does this fit into our user stories?” or “do we have a user story for this feature?”
    • Every feature that gets built and every task that gets assigned should roll up to a specific user story.
  • New ideas? New user stories!
    • If the conversation within the project has taken a new direction, go back and revise to make sure any planned changes are addressed by updates to user story documentation.
  • Steer the discussion and organize notes with user stories in mind.
    • It’s challenging to take a bunch of interesting notes from energizing brainstorming sessions and come out with specific user stories and features.
    • After meetings, try to frame the notes in the context of the original set of user stories.
    • If a new idea doesn’t fit in, write a new user story.
      Make sure there’s agreement among the team and sufficient time and resources before adding to the project scope!
  • Translate new user stories into Jira epics that break down into specific tasks that can be accomplished within the development timeline.

And the Why?

We do this referencing and self-checking on projects so we can avoid redundant conversation and so we have a record of our decisions and process. Keeping tabs on user stories and engaging with them actively also helps us ensure we’re taking cues from our clients and weaving them into what we build, leading to better client and stakeholder satisfaction.

End of this article.

Printed from: https://compiled.ctl.columbia.edu/articles/activating-user-stories/