An Overview of User Stories
/One of the main characteristics of the agile methodology is that project team members do not usually have the luxury of time to document requirements extensively. There’s also the imperative to gather feedback from users as early as possible in the project lifecycle, hence the preference for concise requirements known as user stories. The user story is not the entire requirement but a synopsis of it.
Writing a user story is an interesting way of adding a touch of agile to your projects. A user story can be described as a high-level statement of a requirement that does not go into excessive detail. It describes the functionality or feature that a product is expected to deliver to the user. Stories encourage iterative development and can be refined as many times as possible to reach agreement and understanding among stakeholders.
User stories may be expressed by presenting the role, the goal or the value first. BAs should however. choose whichever format is best for expressing their requirements by considering the context.
The user story is placed as text on an index card and used as a reminder of the conversation between the customer and the developer. It is usually expressed as: Name + Brief Narrative + Acceptance Criteria.
User Story Format
User Story
User Story: Other Side of Card
“As a role (w), I want functionality (x) to achieve business objective (y)”. This approach to writing user stories is regarded as the voice-of-customer approach. An example is illustrated with the images.
Characteristics of User Stories
Stories are normally written on note cards, which contain estimates, notes or specifications on how the software should behave.
Details of the story typically come from discussions with product owners. Story writing requires teamwork. The creativity of the entire team should be leveraged in their development.
Stories generate important discussions that reveal requirements. Stick user story posters on the wall to keep them visible and trigger discussion.
Acceptance criteria are a way of verifying the story - they are users' conditions of satisfaction added to the user story and later used for testing the software.
Story-writing workshops are usually organized to include developers, users, customers, etc. Participants brainstorm to generate story ideas.
User stories are always written from the user’s perspective.
User stories are usually prioritised for each iteration. The prioritized stories are kept in what is known as a product backlog. Priorities can be changed as required.
Stories can be decomposed starting from big/goal-oriented stories (epics) and decomposed into smaller or shorter stories. They may also be organized using themes (grouping related stories together)
Mistakes to Avoid in Writing User Stories
Don't assume there's only one user. Users may vary and may not have the same goals in using a system. When roles are used, users become more tangible and it's easier to distinguish between the different user categories.
Instead of asking users what their stories are, involve them to create a participatory design environment; this has significant benefits.
Not everything to do with the development of the system should be captured in the form of a user story. For example, defects and design ideas don't need to be expressed as user stories.
INVEST in Good Stories
Bill Wake introduced an acronym known an INVEST for writing user stories. Stories should have some key characteristics. They should be:
Independent - Good stories should be independent; this facilitates effort estimation and prioritization. The developer should be able to select a story without pulling in other stories. With this quality, features of a story can be built and demonstrated on their own, without depending on other stories.
Negotiable - Stories are not binding. They are not contracts and should be approached with a reasonable degree of flexibility. Stories may thus be split into several mini-stories and the evaluation criteria should also be relaxed where necessary.
Valuable – Stories should be valuable to customers or the real users of the system; they should deliver demonstrable business value as quickly as possible.
Estimable - Plans for the project are usually based on user stories; stories should contain information that helps the developer arrive at a fair estimation of the duration of time each will take for completion.
Sized Appropriately - Complex stories imply that users will have to wait a considerably long time before value can be delivered. One thing to note is that if the stories do not fit on a card, the scope may be too large. As common practice, user acceptance criteria are written on the back of the card.
Testable - Stories should be testable. Acceptance criteria are used to verify the functionality of the software.
Most user stories will not have all these qualities from the beginning and will need to be constantly revised until they do.
Summary
User stories are not static in time but need to be expanded, negotiated and amended throughout the course of the project. The user story concatenates the viewpoint of different users and as such, may serve different purposes to each user category. It is not purely technical or purely business-oriented; this is why Roy Philips refers to it as the “boundary object”.
