Life of a User Story – Part 1 – Early Stages

More and more organisations are moving away from the traditional Waterfall methodology and embracing Agile methodology when implementing Business Applications.  A User Story is the most important artefact in Agile delivery.  User Stories should not be confused with a Functional Specification.  In this article, I am hoping to give you some insights into the life of a user story.

3 C’s of a User Story

A User Story includes 3 main sections.

Card – Describes the user story

As a [user role], I want to [goal/action], so I can [reason/business value].

Conversation – Provides more information about the feature

Conversation may include wireframes and sketches. Notes and reminders about the features but not the full specification.

Confirmation – The acceptance criteria and acceptance tests for this feature

Confirmation includes success and failure scenarios.

Given [pre-condition], When [action], then [post-condition]

Early Stages

Business Analysts (BA) or Functional Consultants (FC) may create a user story for a given Business Requirement or after a discussion or a workshop with a subject matter expert.  The first step is to write the User Story.

For example, let’s say you were given the following business requirements.

BR-1: Ability to have a rostering system to roster the field staff/contractors

BR-2: Ability to input a roster manually

BR-3: Ability to update rosters manually

BA/FC would then write a user story to cover all the above requirements.

As a Resource Manager
I want to manage the rosters of each field staff
So I can manage their schedules efficiently

If additional information is available, these can be added as notes, sketches, or wireframes in the conversation area of the story.  No more information is necessary and the User Story is about 30-50% complete at this stage, and that’s ok.

During Release Planning, “Effort” for all User Stories considered in scope for the release should be estimated (For example, Fibonacci sequence – 1, 2, 3, 5, 8, 13, 21 …) and Business Value (For example, 0, 20, 50, 100) for the User Stories should also be assigned.  User Stories can then be prioritised based on Business Value and Effort.  Ideally, User Stories with high Business Value and low Effort should be prioritised into early Sprints.  Obviously, some of those User Stories will depend on other User Stories with low Business Value and high Effort which needs to be prioritised as well.  This is a good time to use common sense.

In the above example, you may select, S1, S2, S4, and S23 for Sprint 1 and S9, S27, S3, and S6 for Sprint 2.  The idea is to try and get a better return on investment (ROI).

In Part 2 of Life of a User Story, I will discuss how to write acceptance criteria and acceptance tests to make them ready for development.

References

https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important

https://www.softwaretestinghelp.com/user-story-acceptance-criteria/

Thank you for visiting Dyn365Apps.com.

Follow me on Twitter – Follow @dyn365apps

Until next time…

About the Author

Nadeeja Bomiriya is a Microsoft MVP, Chapter Lead – Dynamics 365 Saturday – Australia, Committee Member – Melbourne Dynamics 365 User Group, Technical Architect, and Dynamics 365 Practice Lead who lives in Melbourne, Australia.

Disclaimer: This blog post contains opinions of my own and not the views of my employer.