All teams can take advantage of Agile principles and practices to reap benefits. Even non-Agile teams can write requirements as stories to achieve higher business value.

WHAT is a User Story?

A user story is a requirement written from a user’s point of view. It contains three critical pieces of information (1 WHO) who has the requirement, (2 WHAT) what the requirement is, and (3 WHY) the reason / benefit of that requirement… but without suggesting how to deliver the requirement (HOW). The most popular format is “As a WHO, I can WHAT so that WHY”. For example “As a customer, I want to complete store checkout process without registration, so that I don’t have to go spend additional time on completing a profile.” In agile, the story format is maintained all the way to team completing that requirement.

It is critical to understand that a user story is NOT intended to be “the source of truth”. Its purpose is to be a VEHICLE for discovering and evolve a common understanding. That’s precisely one of the reasons why HOW is not included… to allow the HOW to be discovered, explored, and even changed.

As teams engage in discussion about each story, they commonly add the following components belonging to each story:

• Description – a more detailed definition of the story… since the actual story is meant to be short and general
• Benefits – a more detailed explanation of the benefits user will experience when the functionality in the story is delivered
• Acceptance Criteria – a more detailed list of functional requirements used to judge whether the story is complete and delivered the intended value

 

WHY is it used?

There are multiple reasons why stories are used and why they would benefit any team:

• Stories force the person writing requirements to understand and present requirements from the point of view of the user / customer. Writing requirements from business point of view misses a key pieces of the information such as user motivation. You focus on what’s important and you tend to be less biased.
• Stories are used to carry the intended unhindered and uninterpreted vision of a requirement from inception through plan through development through testing all the way to UAT. Waterfall and SDLC often rewrite requirements into functional and technical counterparts that loose information in their translation. By maintaining and using the initial vision all the way to testing, you are more likely to build what was intended. No broken telephone. No confusion. It can be easily understood by everyone.
• Stories forces the person developing and testing to focus on the requirement and the benefit rather than on solution design or technical design. In this way, it creates better quality products / features. It also creates better more aware developers and testers.
• Perhaps most important, stories are closer representation of business value then their counterparts. Functional specifications focus on the function. Technical specification, focus on technical execution. Story keeps pointing to the business value. So you get more value.

 

HOW to take advantage of it?

Start with some great tutorials by Mike Cohn. He has a few good ones on YouTube. He also has a great book called “User Stories Applied“.

The next project you’re doing, simply write all your requirements in a format of a story. Get feedback on them from various people involved. There is both art and science to this. You want to avoid prescribing HOW in your story. You want to keep them short. You want to be descriptive. Try making the WHY specific, not generalized.

If you need to write functional / technical requirements, always anchor them back to stories in your original project brief / charter. Use stories as a type of index that guides conversations, estimates, development, testing, and UAT.

 

WHO should facilitate it?

Everyone that is responsible for documenting requirements: Business Owner, Business Analyst, Project Managers, System Analyst, etc.

 

 

Disclaimer: Benefits are obviously more substantial and even cumulative if your team is actually using a complete Agile framework like Scrum or Scaled Agile (recommended). But whether your team is just experimenting, in process of transition, or simply trying to learn… I hope this article helps you on your way.

 

Image credit: QuickMeme.com