Part 1: User Stories – Keeping projects green

Fixing “red” projects is never anyone’s favorite thing to do in consulting. The client is not happy, the team has low morale, your budget is off and the most senior people are usually brought in to help address issues. In my experience, the root cause of most red projects is because standards have not been set, shared and signed off by the client. In this blog, I’ll explore the Definition of Ready (DoR) what is best practice and where the “gotchas” lie.

CORE DEFINITION
In a sentence, the DoR is defined as backlog items that are immediately actionable by the development team for the upcoming sprint and are sized so that they can be “done” within the sprint.

MAIN GOAL OF THE DOR
It provides direction to the project team and stakeholders of a common understanding regarding what makes up a quality user story that can be developed during a sprint. thereby reducing the risk of scope creep, confusion, and project discord.

There are 3 main elements to the Definition of Ready. They are:
1. Use the INVEST acronym as a best practice
2. The User Story structure
3. The Acceptance Criteria structure

1   INVEST ACRONYM:
In 2003, Bill Wake created the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small and Testable) to help teams access the quality of a user story as it is close to being completed. The definition of each of the letters of INVEST are below.

Independent: The story is independent of all other stories. And for the most part there are no dependencies between stories to allow flexibility of scheduling and development. Technical debt stories or Enabler stories tend to be the exceptions.

Negotiable: The feature being designed is not an absolute contract. There is flexibility to allow the scrum team to determine the design of it.

Valuable: The story demonstrates measurable business benefits and enables easier story prioritization.

Estimable: Include enough information so the team can easily estimate the story size.

Small: Smaller stories have less variability than larger stories. In addition, the story must be able to be done within the sprint in terms of capacity.

Testable: The story must be detailed enough so that test scripts can be easily written and are specific.

2  USER STORY STRUCTURE:
Surprisingly, I’ve seen user stories not follow the standard format, defined by The Agile Alliance.  A key point is that the stories must be written in business terms easily understood by the Product Owner and other Business SMEs, avoid technical language and use business terms.  The standard structure is as follows:

Structure	What to write	What NOT to do
As a . . .	Name a role here. This should always be a persona, not a system.	A system is not a role. Think about, the underlying need of who needs this needs this information, and that is the persona which should be listed.
I want to . . .	Insert the action here.  It always begins with a verb.	Use the INVEST acronym when writing this portion.
So that I can . . .	Insert what is needed here.	Use the INVEST acronym when writing this portion.

3  ACCEPTANCE CRITERIA:
The single most common element I’ve seen missing in User Stories are Acceptance Criteria. This criteria is the definitive definition of the functionality in how it will be accepted by the client. AND, the great thing about it is that the language can be used as part of the Test Script. The easiest way to remember the format is that it’s: “Given, When, Then”. Below is detail regarding the structure. 

Structure	What to write	What NOT to do
GIVEN, the user . . .	Doing a thing The need behind the I WANT TO portion of the user story.	Stick with the INVEST acronym when writing this portion.
WHEN, the user takes . . .	An action. This is specific to the user story.	Stick with the INVEST acronym when writing this portion.
THEN . . .	Describe how the functionality developed will act very specifically.	Be EXTREMELY careful here, DO NOT introduce additional functionality, it should be in line with what is in the user story, no more, not less.  If your client wants additional functionality, it should be a separate user story.

IN SUMMARY
Following the Definition of Ready and the guidelines above will add stability to your project. And stable projects mean happy customers and employees. 

In my next blog post, I’ll explore some additional best practices to explore when writing User Stories.