Tag: Agile Project Management

In last week’s blog, I described User Stories and the Definition of Ready. Aligning on a Definition of Ready with clients is a key element in reducing scope creep on projects. 

There are other elements to consider when approaching User Story development, additional definitions or standards and the overall process. 

PROVIDE ADDITIONAL CLARITY
Sometimes a picture is worth a 1000 words. And/or you need to direct the developers easily to the right information via link. Consider these when applicable for your project. 

1. Wireframes, Designs, Diagrams, Links: 
   If there is a visual element to the story, provide attachments to the approved designs. Examples include:
   • Screenshots of functionality to emulate
   • Wireframes using specific tools or hand drawn
   • Designed documents (typically web pages or elements of web pages) with specifications of colors.
   • Process Maps
   • ERDs
   • Links to any of the above or other visuals

2. Data:
Attach data when you can. If it is a large volume,  provide a link or path to find it for the developers. 

ASPECTS OF FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS
The items below will help define more information for each user story.

1. Functional Requirements:
   Definitions of project terms and ways to mark up stories will help the team understand and find user stories. Consider the following two items below.
   • If you have a project dictionary or glossary  including certain functional terms, add them to the story if it will help provide clarity. 
   • Some applications have functionality to add tags or custom fields with different picklist values. These will help you organize and add more information to the user story.

2. Non-Functional Requirements:
Something that can often come up in requirements are non-functional requirements. For example, all code must work in specific versions of Chrome, Safari and Explorer.  

Or there are performance requirements for how fast a query must return results. Or even how the system will be protected from hacking. Add or attach these when needed. 

AVOIDING POTENTIAL ISSUES IN THE USER STORY PROCESS
Below are some tips to consider throughout the life of a user story.

1. Tracking what is sent to the Product Owner (PO) and what is approved by the PO.
   If using Jira, Trello, or other apps, ensure you have 2 statuses marking when the story is sent to the PO and when the PO approves it. These statuses could be something to the effect of:
   • Sent to PO
   • Approved by PO
2. Avoid changing the Definition of Ready mid sprint. 
   Be clear that your project’s Definition of Ready, should not be updated during the sprint. To do so, would add points to each story and the team is likely not to complete the sprint.
3. Beware the never-ending user story.
   This can occur in several places during the sprint. 
   • If the client wishes to iterate on a User Story after it’s been approved, create a new story and put it in the backlog.
   • If during the Sprint Review/Demo, the client sees the functionality, and it spurs on additional ideas (enhancements), jot them down, and state that they can go into the backlog for a future story (and perhaps for the next sprint).
   • Once the user story is approved by the PO, if you can lock down the record from editing by anyone on the scrum team, do so. The purpose of this is to ensure a “well-meaning scrum team member” does not change the scope of the story midstream. If you can’t lock down the user stories, save a  PDF or screenshot of the approved user story (get the date and time in the screenshot too). 
4. Projects with multiple scrum teams:
   If a project has multiple scrum teams, each one must align to the same Definition of Ready, Definition of Done and how they estimate stories. This is to ensure there are aligned standards. When there are multiple scrum teams, clients tend to start comparing one team to another. Below are some of the scenarios that can play out if they’re different:
   • If the different scrum teams calculate points differently, they’ll ask why one team does more work than another.
   •  Or if they have  different Definitions of Ready or Done, clients may ask why one team has more defects than another (and it could be because one team’s definition is not as stringent as the other’s. 

These illustrations demonstrate what not to do, so that you can prevent them so your project runs more smoothly, and your client has a good project experience.

I’ve run into all of these scenarios in my years of consulting and project management. I hope this blog saves you some of the challenges I faced, so that your clients and teams have stellar experiences.

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.