Stories

Stories are like your tasks, but even better. Something we’ve often seen in other tools is tasks like “Account”. Does everyone on your team know what to do with it? Probably not.

TL;DR

  1. 👩‍💻 Write Stories from the user perspective
  2. 💬 Stories shift the focus from writing to discussing
  3. ✌️ Everyone can write a Story

What is a Story?

User Stories are short, simple descriptions of a feature told from the user perspective. They typically follow a simple structure:

As a <type of user>, I want <some goal>, so that <some reason>.

As such, they actively shift the focus from writing about features to discussing them. In fact, these discussions are more important than the written text.

Examples

You can write User Stories at varying levels of detail. Start to add Stories that cover vast amounts of functionality in the beginning:

As a user, I want to have an account, so that I can keep my data stored.

However, while you start working on your project and you discuss all those features, you’ll find yourself seeing more and more details. Start splitting up your Stories into multiple smaller Stories:

As a user, I want to sign up, so that I can have an account.

As a user, I want to sign out, so that I can keep my data safe.

As a user, I want to sign in, so that I can load my data.

As a user, I want to update myemail address, so that I keep access.

As a user, I want to reset my password, so that I can sign in again.

Who writes them?

Everyone can write Stories. Usually, a product owner prioritizes those Stories. Essential Stories are on the top, less critical Stories are beneath.

Where do I put all the details?

You can add detailed descriptions as Notes. Tell your team about why you’re building this feature, about the edge cases and what consequences you’d expect.

For specific tasks consider adding Subtasks. Like “design registration form”, “code registration form” and “add registration to API“.