Following agile? This is how you should create User Stories and give Story Points.
User stories, something that does not seem relative to software development by name. But in agile if I say you can not proceed without user stories then it is very true.
User stories are the heart of agile methodology. Everything revolves around the stories and hence coming up with good balanced stories is battle half won.
In agile software development,
We have product backlog which is nothing but a list of all possible features required to be built to release the product for mass. A full-fledged feature/sub-product is called EPIC and we divide the EPIC into various user stories.
For example,
There is a use case to come up with an online dating website. So this is a huge product and we can divide the whole product into various milestones like
- Implement user accounts and authentication
- Give option to upload your profile and details
- Add payment gateway
- Doing quality match making at real time.
- Add feedback and review section
Roughly, we can call adding contacts, maps and photos as an EPIC and we can divide the EPIC into many stories. The product backlog and stories in the backlog look something like the image given below.
What is a user story and How to create stories ?
As per wikipedia,
A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
e.g As an end User, If I am not a verified user then visiting any product feature behind authentication should redirect me to the login page and prompt to verify first.
A story should follow the mnemonic INVEST which defines all required properties of a good story. User story is a complete feature which is independent enough to be tested and made live.
INVEST — Independent, Negotiable, Valuable, Estimable, Small, Testable.
Now we have to create user stories so that INVEST rule is not overruled.
Taking the above example into consideration, creating user accounts has multiple tasks as given below
We can log stories for these above mentioned features in our project tracking softwares.
If you look at the stories above, you will find that INVEST is followed very well.
Register new user is
Independent — independent to any other story so that it can be made live on its own (We can make it live before adding change password feature but in this particular case all features are required and hence we generally make the whole EPIC live).
Negotiable — any change to the registration is easy to accommodate, But one strict advice is to make changes only before including it into the sprint/iteration. (e.g also add register with facebook or google or twitter)
Valuable — it adds value to the product timeline i.e we move inch closer to the EPIC release. e.g story should not be something like adding database table for user registration.
Estimatable — It is estimable on the basis of tasks involved and the resources required for the same. (user story points should be very clear to every team member)
Small — It is smallest possible complete feature. Granulating the features into smallest and valuable possible stories provide clear viewpoint and delivery date predictions.
Testable — It is smallest possible feature that can be tested on its own, Therefore can be made live on its own as well. Similarly login feature is also testable if we mock the dummy user provided from the database.
Creating good stories lead to parallel development and motivates test driven development as well.
Story Points
Story point is nothing but a measuring unit. In simple terms it’s a number that tells the team how complex and big the story is. Story size is related to complexity, uncertainties etc.
Say you are going on a vacation from city A to city B which is 295 miles away.
I ask how much time would it take to reach B. Can you give me the exact estimate in hours considering traffic, tolls, weather conditions and of course the vehicle condition?
I guess no, because If you say 10 hours then that is inaccurate and a vague estimate.
Now what if I tell you
On this route (for past 6 months) average speed for all medium load vehicles is 50 miles/hours
Gets easy ?
Now you can tell, it would roughly take around 6 hours. (estimate gets better by 4 hours)
Similarly in software development, product manager has a feature. She translates the feature into multiple small stories and can easily make out the required time to deliver as per the velocity of the team.
Astory size can be easily evaluated after some practice. During initial stages, it is not easy to estimate story points so we defined some baseline stories for each story pointer. We used these baselines stories to estimate story points. Depending upon the tasks involved and complexity of the feature, one can easily compare it with other stories and identify the story points.
One must note that Story points are determined by the size of the story not by effort required to complete it. Let me clarify
A login feature is 3 story points as we identified the tasks involved.
An experienced guy can develop it in 4–6 hours while a fresher may take around 10–15 hours. So deciding story points by effort will lead to inaccurate estimates and hence the delivery date can never be defined.
To make it more clear, a racer can travel 100 miles in an hour while an old gentlemen would take 4 hours.
But does that change the distance units?
I hope I made my point. Please find the screenshot of one of our story in the current iteration.
Why Story points ?
If travelling 50 miles is 1 story point, Then 100 miles is 2 story points and 295 is approximately 6 story points.
Therefore comparison gets easy and story point suffices the tasks involved and importance of the story. It helps deciding the complete road-map to deliver 100% and that too on time.
Story points give better idea about how much development we will be able to complete by this iteration end. Therefore the scrum master can easily calculate the no. of iterations required to deliver.
Say the feature is actually 200 story points (consists of 2, 3, 5, 8 pointer stories). If team’s velocity is 50 story points per iteration, it would take 4 iterations to deliver the feature.
The stories in iteration meetings are discussed and then each member of the team gives their story point estimation using planning poker. Any conflicts in story point estimations is then resolved after discussing the team gives final estimate after consensus.
You can use any measure to give story points (Its flexible according to the team’s comfort level as Agile is based on flexibility and adaptability). You can use numbers ranging from 1, 2, 3, …, 10.. or numbers in powers of 2 as 1, 2, 4, 8, 16 …
I prefer Fibonacci series for the same i.e 0, 1, 2, 3, 5, 8, 13 …
Why Fibonacci series?
Larger the story is, the more uncertainty there is around it and the less accurate the estimate will be.
The Fibonacci sequence helps teams to recognize this uncertainty, deliberately creating a lack of precision instead of wasting time trying to produce estimates that might also carry a false degree of confidence.
A Food For Thought?
Fibonacci series is actually used in most of the natures’ wealth as shown below :
Fibonacci pattern
Same pattern in the flower
Almost all nature is based on Fibonacci number
The flowers,
The sea shells
The mother with a baby in womb
Human face and actions
Famous Architectures like Effiel tower and Taj Mahal
Sorry Got distracted. But that is a very interesting piece of information.
Anyways let us get back to the user stories.
Difference between a 5 pointer and an 8 pointer stories is far more significant than 5 pointer and a 6 pointer.
Anything that seems more than 5 we assign it as 8 story points and thus consider all uncertainties in our iteration meetings.
The image given below illustrates the same taking height of the buildings into consideration.
Big stories come with more complexities and uncertainties, so I recommend not to create big stories. If you get a bigger story/feature, Better divide it into two stories following the INVEST principle.
States of a story during iteration
open — Story open for anyone to start development.
start in dev — Under development by one of the team members.
resolved — Story is developed and gets go ahead by the developer for further stages.
start in test — Story is picked up by the quality assurance team to test it.
verified — Story is marked verified by the quality assurance team and ready for staging/live.
closed — Story is made live and is no longer in the queue.
Conclusion :
A story is just a unit that gives better insights and estimations to complete the stories and better product timelines.
Hope this article helps you estimate your stories better and be more productive.
Estimate better, deliver on time and stay on plan with Agile method.
“I am writing it to help you out, you should recommend it to help others out”
Cheer with some claps for more such articles and give your feedback in the comment sectionbelow.
Keep smiling and keep growing.
