Thursday 10 July 2014

What to Consider Before Writing User Stories in Scrum So They Can Be More Effective and Meaningful

User stories in scrum

A user story is the main functional unit in scrum methodology. When any project is taken up for development using scrum, the specific requirements for that particular project is stated by creating a set or development requirements, which are termed as user stories in scrum. Usually the product owner creates the product backlog – the list of requirements needed to develop the project. The product backlog items are referred to as user stories by scrum professionals. Once the product requirement list is created, a small set of the requirements (user stories) are transferred to the sprint backlog during the sprint planning meeting for development purposes. The stories are explained to the team members in the first half of the sprint planning meeting. During the second half, team members distribute the stories after breaking them down into development tasks. A sprint backlog is prepared in this way. Subsequently, the team starts developing the functionalities of the user stories during the daily sprint. In scrum, the entire project is governed on the basis of the user stories.

The official scrum guide does not attempt to provide a specific definition that can describe the “structure” of a particular user story. The guide actually explains what a user story is, and what part it is supposed to play in the project. It fails to provide a standard format which can explain as to how a user story should really look like. Maybe, the reason why the guide fails to provide a structural definition is because development requirements can vary from one particular project to another.  So, it becomes difficult to standardize a specific format compatible to all types of projects.  The guide, however, states that the user story should ideally be composed of three constituent parts, or include there main aspects:

1.     A written description or a graphical representation of the entity which forms a part of the project
2.     A detailed conversation, or an explanation which additionally describes the functionality in greater details
3.     The acceptance criteria or “Done” meaning which specifies what the entity should include, how it should function, and the particular manner how it should migrate or integrate into the project

What should be considered while writing or creating user stories
While writing the user stories, certain points are important, and should be adhered to for the user stories to be effective and developmental:

·       Stakeholders should create or write the user stories
The investors and the stakeholders are funding the project for financial gains. Each project has a financial value attached to it in terms of how much the project will be worth in the market. The stakeholders know which user stories are important, and which functionalities will increase the value of the project. Therefore, they are the ideal individuals to define and create the list of requirements or the user stories. The product owner carries out the work on their behalf, and represents their interests while the project is being implemented.

·       Using simple tools to represent user stories
In the manual system, stories are written down on index or story cards specially designed for scrum. The scrum index cards are very convenient to work with, and are generally pinned on the scrum board while the sprint is underway. It is important to use a tool that is small in size, so it can be easily stored and pinned on the scrum board. It should be easily readable, simple to understand, and effective. The more simple and effective the tool is, the easier it would be for the team to understand and use it.

·       Time to be allotted to the user story
Scrum advocates time bound activities. Each activity in scrum has a certain duration associated with it, and is “time boxed”. It is important not to exceed the time limit to get the most out of scrum. Each user story is allotted a certain duration within which its development should be completed. It is essential that each user story is completed in the time allotted to it since it has a certain importance value (story points) attached to it. The project turns out to be cost effective only when the right duration of time is allotted to each user story, and each story is completed in the time allotted to it. If the time limit is not allotted, the project becomes expensive and its ROI decreases.

·       Describing and stating important non-functional aspects
Certain user stories need to be explained in further details so the team members can properly understand them. The user stories may be very important in terms of how they provide a solution for a particular end-user related requirement. They may or may not be technically complex, but it may be important for the team members to know what part the user stories are likely to play, and how much important they are as far as the overall project development is concerned. Such non-technical aspects of user stories should be explained properly so a better overview and understanding of the project related requirements is availed.  

·       Fixing the story priority
Each user story has a certain level of importance attached to it development. It is important to prioritize the user stories, so the correct time can be fixed for its development. Important user stories, or those which have more importance attached to their development, should be assigned a higher priority, and sufficient time should be allotted for completing them. On the other hand, less important stories ought to be assigned less time and priority because they do not carry much financial value with regards the functionality they offer. .





No comments:

Post a Comment