Strong communication between the customer and the project team is a fundamental ideal of Agile that helps to produce quality results that the customer can use right away. For strong communication to happen, there needs to be common ground; otherwise, the two sides are coming from different cultures and speaking what may sound like two different languages, and this makes communication difficult. User stories fill this gap by framing requirements in a way that facilitates communication between the customer and the project team, and for this reason, they are a critical piece of any Agile project. Keep reading to learn more about what a user story is, how it is structured, and how to write one effectively.

Why User Stories?

User stories serve as a bridge between the business and technical sides of a project. They provide common ground for both sides to discuss requirements at a high level, with just enough detail for developers to estimate the effort required to fulfill them. Using user stories as the communication medium helps generate a free flow of discussion about project requirements, leading to greater accuracy of requirements, which makes estimating and breaking down into tasks easier.

Parts of a User Story

Ron Jeffries (2001, Aug 30) classifies three main parts of a user story:

• Card: an index card, usually 4” x 6”, on which the main statement of the story is written. The statement describes the role of the person making the requirement, what the requirement is, and why the end product needs to fulfill this requirement. It typically takes on the form of “As a (user) I want (function) so that (benefit).” For example, a user story might read, “As a business user, I would like the ability to sort columns by date so I can see the most recent customer interactions.”

• Conversation: Further discussion about the user story, which is recorded on the card. This discussion helps refine the user story further so that it is more clear. For example, some conversation pieces about the above user story might include: What columns do you need sorted? What kinds of customer interactions do you need to capture? What kinds of sorts do you need—ascending, descending, or both? If you are working with a story stored digitally, documents can be attached for clarification. A good piece of conversation is an example, if any can be provided, so that everyone sees what the user wants.

• Confirmation: This is an important step that is often overlooked. Confirmation is where both sides discuss the criteria for how the user story is tested and fulfilled. The customer does not need to design the acceptance test, but the customer needs to be involved in defining it and setting parameters to make it meaningful.

When user stories are completed, they are then estimated by the development team, who assigns story points to them. Story points are not necessarily specific time measurements. They are meant to illustrate how long one story will take compared to other stories. For example, a story with 4 story points should take twice as long as one with 2 story points. Sometimes teams will assign a value to story points, like 2 hours per 1 story point, but this is not necessary; the main ingredient in sizing is the relativity.

Best Practices

What are some best practices to write effective user stories? One model for determining user story effectiveness is the INVEST model, created by Bill Wake, an Extreme Programming (XP) practitioner, in 2003. Each of the six letters in INVEST defines one criterion for an effective user story:

• I: User stories should be independent as much as possible. If too many stories depend on other stories, then it becomes difficult to plan iterations or sprints to handle these because taking one in an iteration/sprint means taking all the others. Some will naturally depend on each other, but it’s important to avoid too many dependencies.

• N: User stories need to be negotiable. It is important that communication can take place around the user story so it can be refined and estimated properly. This negotiation also needs to be able to go on up to the point that sprint planning begins.

• V: User stories need to be valuable. Each story should result in something of tangible benefit being provided to the customer in the project’s result. How much value will be provided depends on the story, and high-value items will likely be sorted near the top of the priority list.

• E: User stories need to be estimable. To be estimable, a user story needs to be clear and specific enough that a team can get together and accurately interpret the requirements, clarify how complex the story fulfillment will be, and determine how long it will take to fulfill.

• S: User stories are at their most effective when they are small. Some stories can be bigger, like epics, but watch for stories that need to be accomplished across multiple sprints. Smaller stories are usually more specific, meaning they are easier to estimate and fit into themes.

• T: User stories need to be testable to fulfill the confirmation criteria. Testable stories have clear criteria and a viable means of testing the criteria. For this reason, user stories also work better when they are more objective or can be refined to a more objective statement. For example, “As a business analyst, I need the database to load quickly so I can make reports in less time” is only testable when the team agrees on what “quickly” means. A couple of specific measures are, “I need to be able to display a database of one hundred entries in fewer than five seconds,” or “I need the database to load fifty percent faster than in the previous build.”

Pitfalls

1. Not being specific enough.

For example, if a story begins, “As a user, I want . . .” there are already a lot of questions. Who is the user? What is his or her background and level of expertise? Many times, teams will go as far as constructing personas for their users that have a full profile of a fictional person who would be using the product. That might not be necessary for each project, but a good way to get a similar effect is to be specific about who is making the requirement and what the requirement is.

2. Not communicating the business value.

If the value of a user story is not understood, then it’s difficult to prioritize it in a list, which makes it difficult to fit into releases and iterations/sprints. To gauge whether stories are communicating the value properly, look at the last part of each statement and make sure that it makes sense and that the value is clear. For example, “As a business analyst, I want to be able to sort one hundred records in less than five seconds so I can make reports faster” communicates a clear value of improving the time spent on a task. Omitting this makes it unclear as to why the story needs to be fulfilled.

3. Not collaborating enough.

User stories will not be refined to the level they need to be if there is not enough communication taking place around them. It is important that regular conversation takes place around user stories so that they go through the full process of development.

Following these steps and avoiding the pitfalls will help teams construct more effective user stories, which will help make estimation and planning go smoother as well and help both the business and technical sides create a quality product.

If you are looking for further assistance, or have a specific roadblock you need to get around, we’re happy to help. We specialize in Agile Transformation. We can help your team successfully implement Agile, or get back on track with Agile with a little bit of coaching or training.

References

1. Jeffries, Ron (2001, Aug 30). Essential XP: Card, Conversation, Confirmation. XProgramming.com. Web.
2. Wake, Bill (2003, Aug 17). Invest in good stories, and smart tasks. XP123. Web.