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.
Source : http://www.agile-scrum.be/wordpress/wp-content/uploads/2014/08/User-stories-Agile-Scrum-Belgium-Training.png
For example,
Some months back we got a requirement to come up with an online resume making 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 existing resume
-
Give option to create a resume for scratch
-
Add payment gateway
-
Creating resumes at real time and deliver the quality resumes as well.
-
Add feedback and review section
-
Add delivery tracking system.
Roughly, we can call user accounts as an EPIC and we can divide the EPIC into many stories.
The product backlog and stories in the backlog looks something like 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
-
Register New User
-
Login
-
Logout
-
Reset password
-
Remove user (if required).
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 could be 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.
A story 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 roadmap 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.
(Capacity planning – http://engineering.naukri.com/2015/09/agile-capacity-planning/)
We play a game five fingers similar to Planning poker to estimate story points at Naukri. We discuss the stories in our iteration meeting and then each member of the team gives their story point estimation using fingers. Any conflicts in story point estimations is then resolved after discussing and 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 …
We at naukri use 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 recognise 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.
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.
Source : http://manifesto.co.uk/wp-content/uploads/2014/08/estimating-in-agile-and-scrum.png
We try not to make any story above 8 points here at naukri, because big stories come with more complexities and uncertainties. We 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.
We have come a long way in identifying very well written and designed user stories at Naukri.
Hope this article helps you estimate better and be more productive.
Estimate better, deliver on time and stay on plan with Agile method.
Stay tuned for more articles on agile !
Related Posts
Posted in Agile
The All-New Naukri iOS App (6.0)