The main reason most projects move to Agile is they would like to see results fast. These result cannot be achieved quickly if there is a lack of clarity on the outcome, this is where user story comes in.
User stories are like mini single line business requirements which tell you the Who for, Why and What to development. Requirements in Agile are written in a story format and not in name-value pair format either - this is because when you read a story you understand better.
|It is easier to understand :|
“As a user logging into the application the first time, I would like to be displayed help popups
|When compared with:|
Users: New login
What: Pop up guide.
|so that I can understand the layout of the screen better”||Why: Guidance.|
In Agile all business requirement should be expressed in user story format, and any requirement which cannot be documented in this format is probably not a business requirement or they do not have a value.format,
There has never been any confusion about who is responsible for a User story - It is the Product Owner. But there are often doubts about who can write them - And the answer is “Anybody”. Anybody who has clarity on the requirement can add details in, usually, if there is a Business Analyst in the team, they would document requirements, and in other teams the team member documents them. In the end, the Product owner should, however, review and accept them.
The user story has elements which have to present and is usually documented in the pattern given in all Agile projects. This helps in bring in uniformity and the structure ensures that none of the components that make a story so powerful is a lot.
|The most common user story Patterns are:|
As a Persona I should be able to do something so that I get this benefit
In order to receive benefit as a role, I can goal/desire
However, there are many attributes of a user story which define and make them:
|A Unique ID||To identify a requirement uniquely. When an ALM tool is used, this attribute is set by default by the team for each requirement.|
|Summary||This is the short name/summary/ title of the requirement|
|Description||This is the user story as given in the user story format|
|Acceptance Criteria||These are the details and the actual content of what is to be developed to achieve the end result.|
There are many formats for writing acceptance criteria, and it could also be just single line criteria. The important point to note is, that if it is not in the acceptance criteria, it is not to be developed.
|Estimation||Every user story is estimated in Story points which is the standProgressard metric in Agile projects.|
|Status||This indicated the completion stage of the user story- It starts from Idea (single line usually) to Defined, Refined, Planned, In progress, Completed, Accepted.|
|When user stories are displayed on Storyboards they are often displayed on Post It notes and referred to as Story Card or just “Cards”.|
This card displays basic and yet enough information to start a discussion :
A user story is only as effective as the discussions on them, and they are only as effective as the participation. Having ceremonies such as Refinement sessions or Amigo sessions is the what makes user stories effective. A user-story written in the correct format is the biggest step, and the next step is getting the acceptance criteria clearly documented.
There are many formats for documenting acceptance criteria -
Just simple sentences or
As scenarios or
As scenarios in Gherkin format (Given.. When.. Then..)
Gherkin format is especially popular in teams where Testing is automated since the Acceptance criteria can be reused, and this reduces any instance of requirement ambiguity or misinterpretation.
Often, non-functional requirements are not documented as stories, and they are a part of the Definition of Done (DOD). Performance, for example, should not be impacted by any story, and the development should be scalable for in every user story. These may be documented for final verification however cannot implement as a separate story.
Requirements in agile projects are negotiable. They can be discussed and modified till they are in the sprint, and even when they are in the sprint when there is better clarity the requirements can be modified. To manage this change and have a central repository it is important to manage requirements in an online tool which would provide a single version of the truth.
There are multiple tools available online such as Jira from Atlassian, Rally, Rational Requirement Composer (RRC), VersionOne etc which provide a platform for managing requirements and also their lifecycle from idea to the acceptance stage.
The detailing of a story card is done through multiple stages of the grooming process. These are broadly classified into 3 stages known as the 3Cs-
Writing requirements in User story format was a practice first adopted in Xtreme Programming. This was a part of involving the end users early and getting their perspective of what has to be developed. In 1998 Alistair Cockburn visited the Chrysler C3 project in Detroit and coined the phrase "A user story is a promise for a conversation.". It is a business statement of what is needed and why. However for the user stories to become effective it is also important that they follow some best practices so that the business and development teams have a common guideline.
These guidelines are referred to as the INVEST criteria, where INVEST is an acronym for :
Agile projects have requirements documented as User stories and approved by the Product owners, and with a self-motivated team which is aware of the business goals working on them, User stories trigger the right conversations leading to best designs.
Your email address will not be published. Required fields are marked *