User Story in Agile Methodology

 It is always enjoyable to think about a new idea but writing our idea in a file is boring sometimes. Most of us do not know how to convert our thinking in a user story where this is the key component of a successful project in Agile methodology. I am going to discuss how easily one can write a user story to build a perfect product.

How do we write user stories?

A user story often follows the following ‘equation’:

As a <type of user>, I want <some feature> so that <some reason>

Let’s break this down one step further;

As a <type of user> — this is the WHO. Who are we building this for? Who is the user?
I want <some feature> — this is the WHAT. What are we building? What is the intention?
so that <some reason> — this is the WHY. Why are we building it? What is the value for the customer?

When describing a product in user stories, there is no good reason to constraint your thinking by budget, time, feasibility, or cost. These parameters can be noted in the requirement analysis phase.

Let’s look at a few simple examples;

As an internet banking customer
I want to see a rolling balance for my everyday accounts
So that I can keep track of my spending after each transaction is applied

OR

As an administrator
I want to be able to create other administrators for certain projects
So that I can delegate tasks more efficiently

And it’s a great question. Though most teams asking this question, usually don’t understand the value of writing user stories, and the fact that they serve very different purposes to that of features.

The fact is, it’s easy to get buried in a contextless, feature developing cycle. The objective becomes more about clearing your way through a laundry list backlog than it is about building solutions that add value to your customers. Your human customers. User stories bring that context and perspective into the development cycle.

Do user stories replace a requirements document?

Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.

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.

It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.

Acceptance Criteria

User stories allow teams to have one hand on the needs, wants, and values of their customers, and another, on the activities they need to accomplish to provide that value.

The link pairing these two things together is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of a user’s requirements. They help the team to understand the value of the story and set expectations as to when a team should consider something done.

Acceptance Criteria Goals

• to clarify what the team should build before they start work
• to ensure everyone has a common understanding of the problem/need of the customer
• to help team members know when the story is complete
• to help verify the story via automated tests

Let’s look at an example of a completed user story with acceptance criteria;

| As a potential conference attendee, I want to be able to register for the conference online, so that registration is simple and paperless.

Acceptance Criteria:

• Conference Attendance Form
• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)
• Information from the form is stored in the registrations database
• Protection against spam is working
• Payment can be made via Paypal, Debit or Credit Cards
• An acknowledgment email is sent to the attendee after submitting the form

Acceptance criteria should NOT include the following:

• The code review was done
• Non-blocker or major issues
• Performance testing performed
• Acceptance and functional testing done

Why?

Your acceptance criteria should not include any of the above, because your team should already have a clear understanding of what your Definition of Done (DoD) includes, for instance:

• unit/integrated testing
• ready for acceptance test
• deployed on demo server
• releasable