As discussed in my previous blog, Scrum User Stories: A Key Communication Tool, user stories are part of the Scrum Agile User Stories_Dos and Donts2-1.jpgapproach that provides a communication technique for discussing the desired functionality so that the end user and the user story's value to the business remain in the forefront as user requirements are developed.

Periodically, I do a routine audit of the user stories in our application to determine if they are being created in the proper format and if they will provide the intended benefits to the team. When I do find issues, they are usually singular issues. Recently, however, I did find one user story that contained multiple issues. The user story was for the validation of data being input into the database. It is a pretty good example of everything that could go wrong with a user story. Remember, I said that user story construction should follow the format "As a [role], I want [feature] so that [business value]." We’re going to break down this user story and analyze what exactly is incorrect about it.

Original User Story Construction (not retouched)

As an API developer, I need to clear front end validation cache, fix a few front end validations and add a few missing front end validations so that validations are fixed.  Acceptance Criteria: Validations are fixed.

Issue #1 - The Role is incorrect

The first question you should ask yourself when defining the role is who really benefits from this work? The role is almost never a member of the development team. If the Role really is the developer, this is probably a task in a user story, not a user story itself. The beneficiary may not seem apparent at first, but you need to make sure you have the right role for the story. In this example, we are talking about what the user sees when they are viewing the form. The user is concerned about the validity of the items they are inputting via the form. A more appropriate role might be "As an online form user."

Read also:  Sprint Planning:  The Most Important Meeting You'll Conduct 

Issue #2 - The Business Value is a repeat

The existing business value, "so that validations are fixed," is vague. This is parroting or repeating the request in the feature section. The value to the business is important, as it aids the Product Owner in the backlog prioritization efforts and the overall understanding of the User Story as it adds context. Without a clear value, backlog grooming will be a struggle. Why is this important to the client? The client wants to view the entries they are inputting and have confidence that they are being entered correctly. Using "so that I am confident the form entries are correct" might be a better business value.

Issue #3 - The Feature is too complex

Previously we talked about a user story containing conjunctions in either the value or the feature section of the user story. This is a perfect example of a user story that is far too complex. This is really three stories:  

  • As an online form user, I need to clear front end validation cache, so that I am confident the form entries are correct.
  • As an online form user, I need to fix a few front end validations, so that I am confident the form entries are correct.
  • As an online form user, I need to add a few missing front end validations, so that I am confident the form entries are correct.

Issue #4 – Weak Acceptance Criteria

Finally, the Acceptance Criteria for this user story is weak and actually is a repeat of the business value. We did not talk about Acceptance Criteria as a part of the user story construct, but User Stories and Acceptance Criteria make up a symbiotic relationship. You can’t really have one without the other. Acceptance Criteria provides a valuable function for the Developer, the Product Owner and the Testers. The Acceptance Criteria acts as a checklist to ensure the feature contains all of the functionality that the client is asking for. For the Testers, the Acceptance Criteria forms the basis of their test cases. In this particular user story, the Acceptance Criteria is where you would list the validations you wanted fixed or which ones were missing. What the client really wants is to ensure that every data entry field has some type of validation so that the database remains error free.

Take another critical look at your user stories and see what could be improved. Doing so can help ensure that business value is achieved and that you maintain a flexible development effort.