An Introduction to User Stories

User Stories are one the main development artifacts in an XP or Scrum project. They are high-level definitions of requirements, containing just enough information so that the developers can produce reasonable estimates of the effort to implement them. Another way to think about the user stories is they are reminders for developers to have a conversion with the customer or Product Owner to get more detailed information when the time comes to implement it.

User Stories are written by the Customer/Product Owner as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. An user story is in very short (couple of sentences) and it uses only customer terminology.

User stories can be written in an informal way , like Students can purchase monthly parking passes online or in a more formal way, following a pattern:

As a (role) I want (something) so that (benefit).

Which makes our example be written like:

 As a Student, I want to purchase a parking pass so I can drive at school.

The more formal way helps the developers to clearly identify the actor/actors, the feature that it requires and why (the business value) of that requirements. In the informal way, all these are not that obvious.

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented. A good approach would be that the customer also specifies an acceptance criteria for the user story in order to help creating the acceptance tests.

If the estimates is too big and cannot fit in an iteration then the story needs to be break down further. During the release meeting new user stories might come up from the split of others.

XP and Scrum have slightly different views on how user stories are estimated. While XP uses the concept of “ideal development time”, which is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do, Scrum uses a more abstract concept of story points, which is based on assigning different values – story points, to each story considering the relative complexity between each other.

Based on the business value (those with bigger added value come first) and the estimates provided, user stories are planned in a certain iteration/release. When the time comes to be implemented, the developer and the customer/Product Owner sit together to detail the requirements enough for the former to implement it.

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point. Epics are typically lower priority user stories, more vague which will get clear in time. It doesn't make sense to disaggregate a low-priority epic because you'd be investing time on something which you may never get to addressing, unless a portion of the epic is high priority and needs to be teased out.

A theme is a collection of related user stories. They are often used to organize stories into releases or to organize them so that various subteams can work on them.

Wanna know more about User Stories?

New Brain Concert open sessions! See the available courses and sign up!