Life of a User Story – Part 2 – Getting Ready for Business

In Part 1 of Life of a User Story, I discussed the early stages of the User Story and how we can prioritise them to get the best return on investment.  In this article, I will discuss what’s required in a User Story before it’s ready to be built.

Getting Ready for Business

Now that we have an idea which User Stories are in Sprint 1, BA/FCs can now spend more time on “Grooming” the User Stories in early Sprints and include Acceptance Criteria and any additional details.  The idea here is not to waste time on grooming User Stories we may never end up building.  For example, we may never build User Story S18 in the above example since it requires high effort for not much business value.

Acceptance Criteria

Acceptance Criteria is about “WHAT” not “HOW”.  Write it in business speak and avoid including any system specific details.  They also should cover positive and negative scenarios.  For example;

Acceptance Criteria 1.1

Given I am the Resource Manager AND logged into the system
When I open the resource record
Then I should be able to configure the following information of the roster

• Work Hours
• Work Days
• Date Range
• Time Zone

Acceptance Criteria 1.2

Given the roster of a field staff member is already configured
When I open the resource record
Then I should be able to modify the roster’s Work Hours, Work Days, Date Range, and Time Zone

Acceptance Criteria 1.3

Given I am not the Resource Manager
When I open a resource record
Then I should not be able to create or modify the roster of the field staff member

Definition of Ready

The definition of ready criteria is a checklist to identify if the User Story is ready to be committed to the Sprint.  The checklist is decided by the team and can vary between teams and projects.  Below is an example of a definition of ready criteria for a specific team.

• The Story is well-written; and has a minimum of 3 Acceptance Criteria defined.
• The Story has been sized to fit the team’s velocity & sprint length; for example somewhere between 1-13 points.
• The team has vetted the Story in several grooming sessions—its scope & nature is well understood.
• The team has the requisite skill-set & experience to implement the Story and deliver it to meet the organizational and teams’ Definition-of-Done.
• If required, the Story had a research-spike to explore (and refine) it’s architecture and design implications; or to explore the testability challenges associated with it.
• The Story describes end-to-end behaviour in the system.
• The team understands how to approach the testing of the Stories’ functional and non-functional aspects.

User Story is now in pretty good shape and ready to be committed into the Sprint.  I would say, at this stage, User Story is about 60-70% complete.  During the Sprint planning session, User Story will be estimated again since it now includes additional details.

It’s Time to Build

The Team must now perform further work on the User Story.  The development team will create tasks to be done.  (Please note: The example I selected can be built using OOTB features and doesn’t require much development work.  The following example is a more generic example).  For example;

• Configure the new custom entity
• Create a plugin to implement the business rules
• Create a plugin to send data to ERP system
• Create Ribbon Button Rules using Ribbon Workbench
• Update User Guide
• Update Design Document

The Test Team must create the Acceptance Test Cases to include system specific details.  The Acceptance Tests for the above Acceptance Criteria may look like below.

Acceptance Test 1.1.1

Given the logged in user has the security role “Resource Manager” AND Bookable Resource record is created
When the Bookable Resource record is opened AND “Show Work Hours” button is clicked
Then the “Work Hours Calendar” page is displayed

Acceptance Test 1.1.2

Given AT 1.1.1 is complete
When “Set Up > New Weekly Schedule” is clicked
Then a new window is opened and the following attributes can be configured

• Work Hours
  • Start Time
  • End Time
  • Breaks
• Work Days
• Date Range
  • Start Date
  • End Date (or no End Date)
• Time Zone

Acceptance Test 1.2.1

Given AT 1.1.1 AND AT 1.1.2 is complete
When the Bookable Resource record of the same resource is opened AND “Show Work Hours” button is clicked AND previously configured time is double clicked
Then following options are available to reconfigure the roster

• Modify the selected date only
• Modify the selected date and onwards
• Modify the entire Weekly schedule from start to end

Acceptance Test 1.2.2

Given AT 1.2.1 is complete
When “Modify the selected date only” option is selected
Then the system displays the time configuration window

Acceptance Test 1.2.3

Given AT 1.2.1 is complete
When “Modify from the selected date” option is selected
Then the system displays the Work Hours, Work Days, Date range, and Time Zone configuration window

Acceptance Test 1.2.4

Given AT 1.2.1 is complete
When “Modify the entire recurring schedule from start to end” option is selected
Then the system displays the Work Hours, Work Days, Date range, and Time Zone configuration window

Acceptance Test 1.3.1

Given the logged in user does not have the security role “Resource Manager”
When a Bookable Resource record is opened
Then the “Show Work Hours” button should be greyed out and non-active

The User Story is now 90-95% complete.  During the build, additional clarifications may be required which might bring in additional acceptance criteria, development tasks, and Acceptance Test Cases.

To recap, so far, the life cycle of a User Story is as below.

In the next article, I’ll discuss what happens to the User Story during the development, UAT, and Production deployment stages.

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.