Understanding User Story

A unique identifier of the user story. traditionally the number used to be like Epic Number.Featurenumber.StoryNumber (e.g. 1.3.1, 1.3.2, 1.3.5, 1.4.1 etc). how ever many ALM tools like Jira, Rally generate the number automatically on creation of new user story. those number can be sequential incremental number for the organization, or can be sequential number prefixed by alphanumerical value to represent groups, projects etc (e.g. ABC123, ABC124, FIN245 etc)

An one liner sentence to represent the whole user story, for easy reference and discussion. A meaningful crisp text to symbolize the requirement. A title for the user story mentioned as example on above section could be “Adding product to cart”

A number to represent the priority of the story in backlog, the lowest number appears at the top of the backlog. to pick for grooming/planning etc. Product Owner or Business Analyst or some time stake holder takes the responsibility to prioritize the backlog by rearranging the rank according to the priority of execution.

This is the section where the details of the requirement get captured, Its consist of Role, Goal, Benefit, Acceptance Criteria, attachments, as mentioned under “structure of user story” section. This section get changes to mature up the requirement by product owner or BA or Stakeholders, The section is advisable not to change after the story is groomed and estimated.

Story points are the measurement unit, to represent the size of a user story in terms of business value or complexity. will discuss on details about story point in Estimation and planning section. The possible values should 1,2,3,5,8,13,21,… in fibonacci series, This is also called as relative sizing.

In the life cycle of a user story, it goes through mane stages from its initiation till deployed to production or ready for deployment. The stages are not fixed it can be customized based on organization need. the basic flow is shown as below

The Good example of workflows for the stages of User stories are also available as below which break down the stages in smaller and better track able units

The Status of the user story to mark it as blocked or impeded and causing delaying its movement in its life cycle.

The possible values are [Yes / No ] or [True / False ] or [Blocked / Not Blocked]

majority of the time a story get blocked during its in-progress stage

Description with the reason for the blockage if any story is blocked or impeded, possible examples are

• Cross functional team has not completed their user story marked as our story’s Predecessor
• Task assigned to UX, has not yet started working, delaying dev work
• Test data not available to do a unit testing

Agile User stories need to be well organized to track the product increment on each level of senior management or portfolio, Each user story can be a child of a feature.

Many practices create sub user story by making another user story as parent, which we advice to avoid if possible.

Will learn more about User story and its hierarchy, later on this page.

This information contain the release number its is planned for, Its an optional information, can be added at any stages of its life cycle.

This information contain the Sprint or iteration number its is planned for, The scrum Master updates the information as soon as the story was committed for a sprint in sprint planning meeting.

Information of the person who created the user story, or currently owning the user story. he is the person responsible for accepting the user story.

Usually tasks are assigned to developer or tester, but many practices do not use task. They keep on changing the assigned-to information with the team member’s name to marking who is currently working on the user story, The Developer , or the tester, or the product owner for verification and acceptance.

Optional value to map user stories with some project code or cost center for other management purpose.

Few Organization or practices create sub stories or child stories under one user story, we personally advice map stories with feature as parent for better mapping and tracking.

Tasks are the bottom most layer in user story hierarchy, and always child of user story. You can create smaller tasks under each user story to estimate the efforts in hours based on the task assigned to resource skill level. example of tasks are

Development, Database Design, UI Design, Testing, ….

Remember the effort estimation on tasks are man hours, it has no direct relation with story points

Successors are the dependent story(ies) linked to your story. The successor story(ies) can only start its development once your story is complete.

for example

Your story : Import Test data for Online purchase functionality

Successor story : Online Purchase functionality enable add product to cart

Predecessors are just opposite of successors, This is also part of story dependency. You can only start working on your story once the predecessor story(ies) are completed.

for example

Your story : Online Purchase functionality enable add product to cart

Successor story : Import Test data for Online purchase functionality

Discussions or threads of comments on each story between Team Members, Stake holders, External team or dependent team. to capture and keep a note on discussions happened during the different stages of a story.

You can map one or many defects to each story to keep a track of defects raised by the testers during testing or verification stage, optionally you can provide option to mark priority and severity of defects, with status like Open / Resolved  / canceled etc.

You can also create and map one or more test cases to your story

Product Owner or Stake holders or BA or any one can provide attachments to enhance the requirement, also testers can attach test results as a proof of testing passed or fail status.

You can map or add one or more tags to your stories, for customize your reports or filtering the stories on your custom category