How To Capture the Technical Details With User Stories

Software development projects have a greater chance of success when they use an agile methodology, rather than a traditional waterfall methodology. The 2011 CHAOS Manifesto found that agile projects had a 42 percent of complete success, as opposed to 14 percent for waterfall projects. Twenty-nine percent of waterfall projects failed completely, whereas, only 9 percent of agile projects were failures. Fifty-seven percent of waterfall projects were challenged to some extent, compared to 49 percent for agile projects.

User stories are one of the factors that improve a software engineering project’s chances of success, and they’re also one of the most common techniques for capturing product functionality in agile projects. A user story is a short description of what a user needs the software to do, often consisting of a single sentence. They must be written in the user’s usual business language and take the user’s point of view. They capture the details of the system’s functional requirements in a concise manner, such that 12 user stories are typically needed to capture one marketing requirement. At the same time, a single user story may include 30 or more specific technical requirements.

User stories provide the basis for defining the system’s requirements and also facilitate the management of those requirements. User stories follow from solid market requirements. Once you’ve identified the problems you are going to solve in the MRD, the user stories further break those down to a story where we can define the product requirements. Product managers often confuse user stories with tasks, especially if they’re new to agile.

Mike Cohn, owner of Mountain Goat Software, says, “A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person.”

The following tips can help you write and execute great user stories.

User’s Perspective

A user story must be written from the user’s perspective and is particularly useful for capturing a specific functional requirement such as making a booking or performing a product search. The user tells a story that the software engineering developer then uses to implement the desired functionality. A developer, therefore, requires a clear understanding of who the users are and why they would want to use the software. This requirement means that product development companies must observe and interview users before they begin writing user stories, thus ensuring that the stories are based on empirical evidence rather than beliefs. According to Cohn, “Even with a well-intentioned and highly communicative team, it is possible that the results of an iteration could be found worthless when shown to the broader organization or external users at the conclusion of the iteration.”

Simplicity

User stories need to be simple and concise so that they’re easy to understand. They should also use active voice and avoid ambiguous terms. User stories often have the following format: As, I want <what?> so that <why?>.

The terms in brackets represent specific information that the user story requires, so each user story must provide a persona, a “what” and a “why. However, this format isn’t obligatory, and product managers can write user stories in other ways.

Epics

An epic is a story that serves as a headline and placeholder, which the product developer will typically refine into multiple user stories over time. The use of an epic allows the developer to sketch product functionality first, without initially providing any details. This strategy is especially useful for describing a product’s new features, since it allows the developer more time to determine the best method of addressing the user’s needs. Epics also reduce the effort needed to integrate new insights into the product backlog. This advantage is due to the general trend that inconsistencies in the backlog become more common as its size increases.

The product developer will break epics into smaller user stories that are more detailed. All members of the development team should have a clear understanding of the user story’s meaning. Furthermore, a user story must be testable, meaning the developers can effectively determine when the story is complete.

User stories must also acquire acceptance criteria as the product developer refines the epics. Acceptance criteria describe the conditions necessary to test the story, ensuring that the story is ready for release to the users. The user story typically has three to five acceptance criteria.

Collaboration

A user story is a tool for facilitating communication between the developers and users, rather than an actual requirements specification. The product manager needs to embed user stories in a conversation, instead of simply handing them off to the development team. Product managers can take this strategy even further and write user stories in collaboration with the development team, often as part of the product backlog process. The advantage of this approach is that it allows the development team to use its knowledge and creativity to create better stories. Use cases are a more formal technique for capturing product functionality than user stories, which product managers should use when they’re unable to collaborate with the software development team.

Early literature on Extreme Programming uses the term “story cards” instead of user stories since they were written on index cards. Even today, developers often capture user stories on paper cards because they’re inexpensive and widely available. Furthermore, cards encourage collaboration between developers since they can be displayed on a table and checked for inconsistencies and dependencies. Developers may then store the user stories electronically once they’re complete.

User stories should remain highly accessible since their primary purpose is to communicate information. They should not be placed in a restricted location such as a private network, company intranet or proprietary tool. User stories should be placed in a visible location such as a wall in the development. This practice promotes the collaboration and transparency that user stories need to be useful. A physical location also has limited space that helps to illustrate when stories are added too quickly.

Technical Requirements

User stories are most useful for capturing product functionality, but they aren’t well-suited for describing the user experience and visual design of software. Developers therefore need to complement user stories with other techniques, such as sketches, storyboards and workflow diagrams. Furthermore, developers shouldn’t use user stories to capture technical requirements. A technical story or modeling language is more appropriate for communicating a system’s architectural elements. Finally, user stories are most useful for reusable software and may not be necessary when developing a prototype for the sole purpose of validating a design idea.

3Pillar Global brings out the best in agile with our Adaptive Product Lifecycle Management which makes breakthrough product ideas a reality. Contact us to learn more.