ALL >> Hardware-Software >> View Article
Writing Effective And Useful User Stories – How To Reduce Regression In Scrum
Total Articles: 48
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:
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.
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.
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.
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]
Hardware/Software Articles1. How Relevant Is Software Testing In A Devops Era? Top 5 Reasons
2. Uses Of Accounting Software
Author: Ayisha S
3. Become A Smart And Successful Laptop Repair Engineer
Author: Natasa Suri
4. Essential Benefits Of Co2 Laser For Acrylic Cutting, Marking And Engraving
Author: Rob Hibbs
5. Empowering Finance And Banking Sector With Digital Technology
Author: Shreya Verma
6. Do You Know The Live Stream Apps Changing The World?
7. Top Reasons Why Every Hr Manager Should Use Employee Management Software
Author: Anish Desai
8. Why No Padlock On My Web Browser Or Website?
Author: Gaurav Maniar
9. How To Build The Right Selenium Testing Strategy In 4 Ways
10. Why It Is Important To Have Ms Office Within Office Environment
Author: Carl Smith
11. Why Laptop Screen Repair Should Be Done By An Expert In Mumbai
Author: Mike Rakhangi
12. Steps To Fix Error Code: “8504, 104” And Download Norton Setup
Author: Robert Coleman
13. Rise Of Automation, Robotics And Artificial Intelligence -2018
Author: Kiran Paneri
14. Dell Printer Support At Your Service Within Minutes
15. How To Choose Best Printers For Small Business?
Author: kifnfo it solutions