September 26, 2017

Defining Done: Understanding User Stories

A website redesign can be a daunting undertaking. As soon as an organization embarks on this kind of project, the jargon starts to fly. The amount of technical know-how that seems necessary to make intelligent, informed decisions can feel paralyzing.

Internal business stakeholders can be difficult to wrangle. Everyone has an opinion. Different divisions have different priorities and goals. Executives are capable of the proverbial swoop and poop at any moment. In all the noise, it can be hard to not to lose sight of the needs of your users, the problems are that they are trying to solve, and the information they need to feel inspired to take the actions you want them to take.

User stories are a great tool to help define your fundamental website requirements in a friendly, easy to read way. They’re designed to get everyone talking instead of writing elaborate specifications, and to empower business leaders to shape the features and functionality of a site without deep technical expertise. Requirements are a collaborative process. Every stakeholder and every team member has something to add. User stories have another key benefit. They keep the focus of a website redesign where it belongs: on how your site addresses the needs of your internal and external site users.

Users stories help us define the “what” of a website, and keep us out of the “how.” Kanopi Studios uses a structured format for user stories, as described by Mike Cohn in his book User Stories Applied. This helps us ensure that stories are as clear as possible. Our user stories follow the format:

As a [type of user], I want [their goal] so that [the benefit].

This puts the emphasis on what users of the site need to achieve, and what the system must do to help them reach their goals. It is a plain-language way of mapping out our system requirements. All components of a user story are of equal importance and must be included for a user story to be considered complete.

  • Type of user – Who is this person? A site administrator? An anonymous visitor?
  • Their goal – What does the user need to be able to do?
  • The benefit – Why does the user need to be able to perform this action? This provides critical context for developers when determining how best to implement the story. It also helps us ask the hard question: if we can’t clearly define how something benefits a user, does this feature or function even need to exist?

In addition to the structured format, user stories have “acceptance criteria” that go along with them. These criteria help us define what “done” really looks like. Acceptance criteria define success. They are the granular set of conditions that a story must meet to be considered correctly implemented.

Having a clear, shared definition of done makes the website development process a breeze. The finish line is easy to see and it doesn’t move… even if we have to make a few detours along the way. Business stakeholders have clear, specific language that gives them confidence that the new site will meet their needs. Developers have enough information to make smart decisions rooted in the business benefits of a feature. And the project has a single source of truth for the requirements for the site, so we are all working towards the same goals. By framing your requirements as user stories, you help ensure shared understanding across your team and set the course for a successful website development project.

Need help defining your user stories? Contact us.