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