We're Hiring

What are User Stories?

It's easy to think of software as a purely technical endeavor but, for the most part, it really isn't; at the end of most software is a user.

It makes sense then, when planning a project, to think first of all the things a user wants to do, then work back to a technical plan on how to do it. A user story is just that, an "end goal" as required by a user, it's not a technical integration plan or a development process but rather an outcome that will provide value to a user.

Where do we start?

In essence, the first thing you want to do is identify all the types of users. Here are some examples:

  • Admin
  • Customer
  • Staff
  • Manager

Then you want to start writingthings the users can do in the following format:

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

These can be written on a post-itnote, excel, word doc, or a whiteboard (anywhere) and they canbe in varying levels of detail. For instance, consider this example for screen recording software:

As a user, I want to be able to record my screen.

This does a pretty good of describing functionality but what if we broke this up a little more?

As a user, I want to be able to record my active window, so that only the current window I am working on will appear in the video.As a user, I want to highlight the mouse in a screen recording, so that it's easier to see the mouse position in smaller video formats.

Once you've completed all your stories, feel free to take a story and split it into smaller, more detailed stories like the example above. The more detailed the stories are at the planning stage and the more reasons included in them can spark a discussion on the best way to achieve the desired outcome and open up new possibilities.

What if a user story changes?

Great. The Agile process should be just that: Agile. During the project, we may discover that user stories need to change, we should be open to that possibility and ensure we're ready to change if we find out a better way of doing something or have a new requirement.

Specifying out the details now doesn't shoehorn us down the wrong route, it just gives us a better map to follow.

What happens to user stories throughout the project?

We'll use user stories as the backbone of the project, effectively replacing a specification or requirements document in a typical project. We'll turn each of those user stories into a set of technical requirements which is the functionality we need to build in order to meet that user requirement. This is known as a project backlog and it's what we work on day-to-day in our sprints. If you want to find out more about the sprint process you can read more here.
As a user, I want to use user stories, so I can deliver value to my users.