First thing that should be done before Scrum project launch is defining user stories. These can be compared to well known use cases, however they are not the same. This article is worth reading first, if You are new with Scrum.
Use Case versus User Story
Use case is general term specifying area in which product will be used. For example a car can be used in one case in company for a salesman transportation tool or – in another case – at home in family’s every day life. Wiki article section describes in simple manner.
User stories defines details of certain use case from the users point of view. They are based on the following template:
“As a <product user> I want <what> so that <users benefit>“
The goal is to look at the product from the users perspective and deliver products that suits their needs. Sample user story may look like:
“As a salesman I want car to be equipped with GPS so that I can easily set my direction”
You can define as much user stories as You wish – it depends on project complexity.
I. N. V. E. S. T. in User stories
Well prepared user stories should follow the INVEST idea. Its theory is well described here (begin with slide 12). Further in text You will find some practical clues.
User story should fit sprint
The biggest user story should be small enough to implement it during one sprint. It is possible to build small stories although it requires a bit of work. During sprint itself the user story can be divided into small tasks and distributed in self organizing team.
Definition of done
Each user story needs a criteria of completeness. This is the moment when nothing more has to be done to fulfil it (for example: salesman can reach his goal thanks to GPS in his car). The team should implement functionality having definition of done in mind. Team should not be predictive and add new things that overrides the done definition. These will be added in next user stories.
User story’s complexity and priority
Priority depends on business requirements and/or technical constraints and probably there will be no problem with defining it.
Complexity is a bit more difficult to evaluate. This process begins with assessment of one user story that is easiest to estimate (basing on team experience). The latter user stories are compared to stories already assessed. Team decides if tasks connected with it are more complex or not, and how much. It is easier to compare unknown task to the known one and assess it, than assess unknown task from scratch.
Complexity unit
There is no complexity unit :) You just give it some value without a unit. Nor days neither hours are used. If user story has complexity 8, and another one seems to be much more complex You give it complexity 40. There is no need to measure it in days or hours. You just see that one task is 5 times more complex than another.
Planning poker
Complexity values, given to the user stories, are taken from the Planning Poker subset:
0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (unknown)
It is easy to define complexity accurately if it is small. If it is bigger – it is difficult and not needed. It makes sense to say that something is 1,5 meter long in opposite to say that something is 1000,5 meters long. This 0,5 meter is not significant in latter case.
Planning poker has simple rules: each team member chooses one card from his set and estimates task on his own. Then each member shows his card and agree on complexity value after short discussion.
Product backlog is a set of user stories
Functionalities that come from user stories should be put in a product backlog. They should be ordered according to priorities and have complexity assessed. Team chooses user stories that will be handled in upcoming sprint.
Common mistakes
User stories are written for user (not for Product Owner, Developer or anyone else). Each user story corresponds to benefit to user. Read some valuable clues here.
Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality
Thank You!
Looks OK! 