Part 2: User Stories – keeping projects green

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.