A lesson in User Stories in an Agile – Scrum environment

Quality of user experience designs depends on the quality of requirements, ie, user stories.

While it is possible to cook bad food from good ingredients, it is not possible to cook good food from bad ingredients.

EpiCs and user stories in today’s agile Application Development process

Agile development processes really are the savior in today’s UX/UI design world and I feel this absolutely saves product development time and money. Sometimes, analyst took this method to far.

What I mean by that, is in Scrum Agile processes, User Stories have replaced the well known User Requirements, back in the day, in Systems Development Life Cycle (SDLC) process.

User Stories START OFF as a uniform statement of a feature that has a three components; ie, role, action, added value.

As a [UX Designer] I want to [embrace agile] so that [I can make my project user-centered]

As a [runner] I want to [buy a sports watch] so that I can [track my run times].

Ahhh, then why did the initial sprint review have some blunders? An agile methodology was utilized… we had daily stand up meetings.

The answer, single high level statements are incomplete User Stories. User stories need to be more granular and groomed- discussed with Product, Stakeholders, UX and UI designers before the design process begins.

Here are a few things to remember when constructing user stories:

  • Identify a full set of user stories before doing any visual design. Resisting the temptation to jump straight into designing may save time and headaches and lots of wasted effort.
  • For each user story, see if it can be broken down into smaller, more specific stories. “Epics” are fine for a high-level overview of the needed features, but don’t leave things too broad. Drill down to the specifics early on, and solve usability problems at the outset.
  • Never put a design element in an interface that doesn’t have a corresponding user story. Documenting the what and why of each element promotes organization and makes the handoff to the development team much smoother.

Every user story includes three main characteristics:

  1. It tells the story of the problem or need that the user will solve through a particular piece of product functionality.
  2. It’s meant to be a living story that can be updated and modified as a project evolves
  3. It provides sufficient information for developers and designers to understand the functional need, but doesn’t go into the details of how these should be addressed from a technical or design perspective.

Another takeaway, grouping User Stories into Epics is helpful when designing initial wireframes and lo-fidelity mock-ups.

Leave a comment