Context: If you don’t get
the user needs right, it does not matter how well you execute the rest of the
project. Requirements are the foundation for all the project work that follows.
The purpose of a software development project is to build a product that provides
value to a particular set of customers. Thus the customer involvement is the
most critical contributor in eliciting requirement process.
Let us go through famous survey output on this context. The Standish Group
surveyed IT executive managers in 1995 for their opinions about why projects
succeed. The three major reasons that a project will succeed are user
involvement (15.9%), executive management support (13.9%), and a clear
statement of requirements (13%). Opinions about why projects are impaired and ultimately
cancelled ranked incomplete requirements (13.1%) and lack of user involvement
(12.4%) at the top of the list. In his now classic ROI presentation at XP 2002
Jim Johnson shared research regarding the productivity achieved by those
software projects that do deliver something. Among these, Jim found that 45% of
product features are never used. 19% are rarely used and 36% are routinely
used. This tells us that traditional requirement engineering practices are not
helping us delivering value to our customer through our traditional practices.
In my experience, traditional requirement engineering practices applied through
waterfall models has numerous limitations, including the following:
1. Why? - It is difficult
to correlate each requirement with corresponding end business value it maps to.
Thus, it is becoming difficult for the development team to understand the
business reason behind each of the specified requirements. This also leads to
ineffective prioritization and thus impacts ROI based decisions.
2. Who? - It is difficult
to understand the mapping between each requirement and the person who uses it.
It creates huge gap between users and the developers.
3. What? - It is difficult
to keep requirement documents current and synchronized especially when the project
involves multi-site and multi-group involvement.
4. Users’
perspectives or Business Analyst’s interpretations: Often, we see standard requirement
specifications leaning towards Business analyst’s interpretations over clear
capturing of user perspectives.
5. De-focus: Lengthy
Requirements descriptions may derail developers in understanding exact intent
behind the requirement specification.
6. Changes Happen - It is
inevitable that the requirement will change. Business needs evolve, new users
or markets are identified, business rules and government regulations are
revised and operating systems change over time. When changes happen to overall
business goals, it is difficult to reflect that change across the associated
requirement specification documents pertaining to various products.
7. Exact User
Acceptance criterion is often not clearly known to developers when they
build the features. This often leads defective products.
8. Even Best
Requirements documents cannot – and should not – replace human dialogue.
We often see limited interactions with users and more focus towards documents
and processes. This leads to defective product feature implementation.
9. Validation of
requirements does not often
take place against business ROI and user satisfaction. This leads to less usage
of product features and less profitable
10. Periodic
Feedback is not enabled
between the users and the developers in waterfall development model till User
Acceptance testing. Thus, it incurs huge cost to incorporate User feedback as a
result of User Acceptance Testing.
What happens in Agile? Kent Beck coined the term User Stories in Extreme Programming in 1999. User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. The essence of user-centric and usage requirements elicitation is to focus on what user wants to have, not what user wants system wants to do.
Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the user stories to be developed in a product or service. Let us learn these basics in detail.
User Story is accompanied with Acceptance Criterion
User Story typically follow a simple template:
As a <type of user>,
I want <to perform some Task>
so that I can <achieve some goal/benefit/Value>.
User stories need to be confirmed with below 3C guidelines suggested by Ron Jeffries:
1. Card: User
stories are traditionally written on index cards or sticky notes in short from.
User Narratives are used to further explain these Cards. Thus, the main
intension is to describe the User story in short form to allow common
understanding on User need among all stakeholders.
2. Conversation:
User Stories shift the focus from writing about features to discussing them. In
fact, these discussions are more important than whatever text is written.
3. Confirmation:
Acceptance tests confirm the story was delivered correctly
Let us take an
example,
User Story Title: Customer Withdraws the Cash.
As a customer,
I want to withdraw cash from an ATM
So that I don’t have to wait in line at the bank.
Acceptance Criterion- 1:
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests the cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Acceptance Criterion-2:
Given the account is overdrawn
And the card is valid
When the customer requests the cash
Then ensure the rejection message is displayed
And ensure cash is not dispensed
User Story Title: Customer Withdraws the Cash.
As a customer,
I want to withdraw cash from an ATM
So that I don’t have to wait in line at the bank.
Acceptance Criterion- 1:
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests the cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Acceptance Criterion-2:
Given the account is overdrawn
And the card is valid
When the customer requests the cash
Then ensure the rejection message is displayed
And ensure cash is not dispensed
Product Backlogs and Epics: User stories are written throughout the
agile project. Usually a story-writing workshop is held near the start of the
agile project. Everyone on the team participates with the goal of creating a
product backlog that fully describes the functionality to be added over the
course of the project or a three- to six-month release cycle within it.
Some of these agile user stories will undoubtedly be epics. Epics are large User stories and will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.
Some of these agile user stories will undoubtedly be epics. Epics are large User stories and will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.
While a product backlog can be thought of as
a replacement for the requirements document of a traditional project, it is
important to remember that the written part of an agile user story (“As a user,
I want …”) is incomplete until the discussions about that story occur.
Anyone can write user stories. It's the
product owner's responsibility to make sure a product backlog of agile user
stories exists, but that doesn’t mean that the product owner is the one who
writes them. Over the course of a good agile project, you should expect to have
user story examples written by each team member. Also, note that who writes a
user story is far less important than who is involved in the discussions of it.
Agile helps us get
the requirement right:
1. Why? - User Story
clearly describes the goal or benefit the user is trying to achieve through it.
Thus, it is easy to correlate each User story with corresponding end business
Value it maps to. Using KANO and MoSCoW prioritization techniques, Product
Owner can optimize Product’s ROI.
2. Who? – User Story starts
with the persona who is needed this functionality. Thus, it connects users who
consume the capability with the developers.
3. What? –In Agile, One
Product will have one product backlog. Product Backlog can be sub divided
into Product Area Backlogs for the respective multi-groups. In this format,
User stories can be grouped under epics so that we can establish common
understanding about the user cases across the Product Backlog.
4. Users’
perspectives: User Stories are written to capture user perspectives only . We also
capture User Acceptance criterion upfront for the related user story. This
indeed offers great help to Developing team.
5. Focused: Use stories are
short form of User’s need. We capture all the related information in User
Narratives. This helps development team to understand the exact intent of the
user need.
6. Changes Happen: User stories
recognized the importance of the change. User stories absorb the change through
below means.
·
If the scope of the user story becomes large, they can be split into
smaller user stories
·
By adding “conditions” to acceptance criterion
7. Exact User
Acceptance criterion is clearly known to developers upfront. This leads
better connect between Users and Developers and thus facilitates collaborate
value driven path.
8. User stories using 3 C guidelines human dialogue. Please remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.
9. Validation of User
Needs is clearly
documented through Acceptance criterion and the same is captured for each User
Story. This ultimately leads to User Satisfaction as it is communicated
early to developer community.
10. Periodic Feedback is enabled
through Sprint Reviews in Scrum Framework. Thus, Users are given working
software well upfront and their feedback is periodically incorporated into the
Product iteratively.
Conclusion: Agile projects are successful three times more often than non-agile projects, according to the 2011 CHAOS report from the Standish Group. The report goes so far as to say, “The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.” (page 25). In this process, Agile User Stories certainly act as build blocks for software project development success.
References:
1. http://www.mountaingoatsoftware.com/blog
2. http://agileproductdesign.com
3. “Software Requirements” by Karl E Wiegers
4. “User Stories Applied: For Agile Software Development” by Mike Cohn.