Writing Effective And Useful User Stories – How To Reduce Regression In Scrum

By Author: mrugesh panchal
Total Articles: 48
Comment this article

Each day product owners face new challenges as far as user stories and their acceptance criteria are concerned. It is imperative that correct criteria be defined and stated in the product backlog items. The development team should be educated about the user stories and familiarized with the benchmark set up for each backlog item. The team should put in enough efforts and clearly understand what needs to be developed, and in what manner, so that the development carried out by the members is “shippable”. During the sprint review meeting it is very common to hear the team say that the acceptance criteria was not made clear or was not correctly defined by the product owner, and as a consequence user stories could not be developed correctly. While implementing scrum methodology, regression is an important concern for the management since it leads to increased overheads and reduced investment returns. In reality, scrum methodology supports several practices for gathering authenticated feedback from the work process and identifying key factors responsible for the regression. ...
... Scrum framework supports self-realization and self-correction activities. The main purpose of the sprint reviews and the sprint retrospective meeting is to reflect upon the prior sprint and find out what has worked well and what has gone wrong in the sprint. When proper steps are taken to check the regression occurring in the daily sprints, several factors are identified and come to light, which may be affecting the way in which unsuccessful user stories are inadvertently developed by the team. However, whichever way you analyze and look at the root causes, the main issue turns out to be poorly defined product backlog items or improperly explained user stories. Whether the product owner did not spend enough time and efforts in writing the user stories, or the development team failed to understand the acceptance criteria in the backlog items, the fundamental issue associated with the backlog items should be properly addressed and resolved if positive results are to be availed through scrum implementation.

Writing understandable and effective user stories
Contrary to what most scrum professionals believe and the hype associated with difficulty levels in creating meaningful and effective user stories, in reality it is not so difficult to write effectual backlog items, if you follow a few simple steps. The product owner should focus upon the three fundamental aspects associated with user stories:
1. Role
2. Feature
3. Reason

Consider the following postulate:
As a [role], I can [feature], so that [reason]
For example - As a marketing executive, I can check the daily online inquiries, so that I can send emails explaining product features.

“As a”
This specifies the role of the end user making use of the features and functionality offered by the product. Each user assumes a specific role while using a particular product. An individual accessing or using the employee attendance features of the product may be a HR manager responsible for keeping tabs on the daily employees attendance. A person accessing the daily appointment features provided by a system may be a receptionist working in a hospital or a health institution. The “As a” typically defines the role of the person. This is important since the development team should be aware about exactly who is going to use the product and in what manner. It would help the team to define the functionality of the user story and ascertain the manner in which particular feature is supposed to work. A receptionist may need limited details about the patient appearing for the health checkup, but the physician or the doctor may need patient case history details during the consultation. Two distinct roles are visible in such a situation – the role of the receptionist and that of the doctor. The role undertaken by the user is important and should be clearly defined an explained in the backlog items.

“I can”
This aspect defines what needs to be done with respect to the user story. In most cases, this aspect requires the features to be clearly defined and explained by the product owner. It is the main activity to be carried out by the user, and in terms of development, it conveys what type, manner, and nature the development should ideally consist of. For example, the receptionist may need to just display the list of daily appointments while the doctor might require the case history details exhibiting the health records, prescription details, date of visits, follow-ups of patients, changes occurring in the blood pressure levels, etc. This part forms the heart of development activity carried out by the team, so it should be clearly stated and defined.

“So that”
This specifies the objective or the result desired out of the user story activity. It specifies what should be ideally achieved out of the development activity, the result thereof with respect to the development carried out. It is also the target to be focused upon by the team while developing the backlog item. In the above example, the receptionist may be required to pin the daily appointment list on the visitors board or send a copy to the doctor before he or she begins the day, and the doctor may be able to compare the medical findings and reach to a proper plan of treatment based upon the clinical details made available to him or her by the system.

Variations to the rule/postulate
Scrum is all about adapting to changes and incorporating the changing market conditions within the product development cycle. It is important to be flexible in scrum as the product nature and market conditions may change with time. In many instances the final product developed through scrum might be very different when compared to its original release worked out during the project inception stage. It is important for the user stories to adapt to these changes if they are to remain effective for the team.

The product owner can work out different variations to the basic rule by interpreting the rule in different ways and manner:
• As a [role], I can [feature]
• As a [role], I want [feature], because [reason]
• As a [role], I should [feature], so that [reason]