When I started my current project as a Functional Analyst last year, I was advised to write user stories in the form of “As a <user>, I want <goal> so that <reason>”. It is a unique way to document the stories but definitely simplifies various challenges of the requirements documentation.
By learning how to gather requirements as user stories, I realized how agile plans are always kept up-to-date, contain only the latest and greatest information, and avoid one of the greatest wastes our industry has ever known—premature up-front analysis.
The key challenges that teams run into when they heavily rely on documentation for their software requirements are that:
- They can’t handle changes effectively
- They build according to specs instead of what the customer wants
- They make bad guess and false assumptions
- They waste a lot of time
So, Is a requirement really a requirement? If I put it in words of Kent Beck, one of the 17 original signatories of the Agile Manifesto, then the term ‘Requirement’ is just plain wrong.
“Software development has been steered wrong by the term requirement, defined in the dictionary as something that is mandatory or obligatory. The word carries a connotation of absolutism and permanence, inhibitors for embracing change. And the word “requirement” is just plain wrong.
Out of the thousands of pages used to describe requirements, if you deliver the right 5, 10 or 20 percent, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80 percent? Not requirements—they weren’t mandatory or obligatory.”
The problem with gathering requirements as documentation isn’t one of volume—it’s one of communication.
- First, you can’t have a conversation with a document
- Second, it’s just really easy to misinterpret what someone wrote
This leads us to one of the most important principles of agile:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
So, what we need is something that enables us to have a conversation about a requirement, captures the essence of what our customer wants, and is small enough for planning yet descriptive enough to remind us what we are talking about …ENTER A USER STORY
Agile user story is a short description of a promise of a conversation. Agile encourages the user stories on index cards to remind teams that the initial goal of the requirements-gathering exercise isn’t to get into all the details. It’s to write down a few key words to capture the spirit of the feature and file it away for a later date.
Why just few key words? To save us the time and energy of going all in it now and having to redo it all later, we defer diving into the low-level details until later.
User stories have to make sense to business. That’s why we always try to write them in simple terms and try to stay away from any technical jargon. It is better if we put the information in terms that business understands.
A really good user story is one that goes from end to end - slicing through all the layers of the architecture and delivers something of value. The good user stories are Independent, Negotiable, Testable, and Concise that can be Estimated easily.
A few short, well-chosen words are usually enough to remind the team about what a particular user story is about: that brings up our User Story Template in existence
AS A <USER> I WANT <GOAL> SO THAT <REASON>
The nice thing about this template is it answers three important questions about the user story: the who, the what, and the why. It gives a little more context and really emphasizes and focuses on the business, which is a good thing.
Popularity: 16% [?]
Leave a Reply