Stories are small, incremental pieces of functionality that capture what a user needs and why. Multiple tasks are associated with each story. Stories are sized to fit within a single sprint.
There are two types of stories, User Stories and Enabler Stories. User Stories, which are typically used to replace traditional requirements, are the primary means of expressing needed functionality. User Stories are value centric. They focus on the user, and not the system. To support a value-centric, user-focused story, it is best to write in a user voice form. The recommended format follows:
As a (User Role) I can (Activity) so that (Business Value)
This format provides the team context as to who the user is, what they will be doing with the system, and why they are doing it. Below is an example of a User Story.
As a ratings manager I can view the number of viewers of the shows during the time slot I selected so that I can see how the current show is doing compared to other shows during the same time slot.
Teams also need to develop technical functionality to implement user stories or other system functionality. These stories may never touch the end user. These stories are Enabler Stories. Enablers, sometimes referred to as spikes, can be used to support exploration, architecture, or infrastructure. These stories can be written in more technical terms rather than the user voice form.
Shawn Kessler
4 comments