Writing Great User Stories

Aten uses agile methodologies to bring clients value, control, and flexibility in development. Agile allows you to engage in just-in-time planning to allow the team to embrace inevitable change that occurs in a project when working with people. Agile works extremely well on products under ongoing development that never really ends. It is more challenging to use Agile for building Web applications. However, many of the techniques and strategies used in agile development segue extremely well to Web development. One such technique is user stories. There are essentially two kinds of stories: epics and user stories. Epics are large user stories that describe general functionality. They often span multiple development sprints and are usually too large to estimate on without breaking them into smaller pieces. You might describe search, blogs, forums, or a knowledge base using epics. Below the epics, stories are laid in. User stories are designed to describe business value in small pieces. They should help your client understand something that a visitor or user of their web property would experience. Stories are one or two sentences that describe the Who, What, and Why of that something. They are normally written in the following syntax: As a [who], I want to [function], so that I [experience something of value]. User stories help you always think about functionality with an eye to business value. The idea is to avoid introducing too much detail too early in the process. Engineers should be looking at the story and determining the best route to reach a victory state on that story. Stories should be small so it is easy for everybody involved to understand them. They also become the basis for a client’s acceptance tests. Bill Wake created the INVEST mnemonic device as a litmus for good user stories.

	Meaning	Description
I	Independent	The best stories can be worked on in any order independent of each other. Ideally you do not want there to be dependencies.
N	Negotiable	Too much detail makes it difficult to discuss and adjust the approach for a story. They can be altered and rewritten until they are added to a sprint.
V	Valuable	Stories should always deliver some kind of value.
E	Estimatable	Stories should be small enough that you can accurately estimate how much time they will take.
S	Scalable	Stories should be small so you can plan, task, and prioritize them easily and consistently.
T	Testable	Stories should be testable. They should ease the testing process and the victory state should be clear.

If you ask for a client to “review the home page and let us know what you think”, there may be many little things that prevent them from signing off on the entire page. When a story is small and understandable to a client, it becomes much easier to determine whether a victory state has been reached for each element. However, if you break the page up into logical functions and ask the client to sign off on one piece at a time, it becomes much simpler to sweep distractions out of the way and agree that things are complete. User stories are a great way to describe functionality clearly to clients, set up developers for success by breaking things down in logical ways, and create a roadmap for acceptance when a sprint is concluding. Writing smart user stories is critical to the success of an agile process.