We definitely need estimation to plan our software development, in agile we do estimation in little different way than traditional effort estimation, its easy, interesting and yes effective too.
In Agile Estimation we can estimate at its different hierarchy item ( read about story hierarchy ), in this article we are focusing on estimating user stories and its tasks.
Traditionally we use to estimate efforts to develop a functionality, where in agile we estimate Business values or Complexity of a user story level. And estimate efforts in Task level. The unit of estimating user story for its value or complexity is story points, and the unit of estimating a task for its effort is Hours.
We usually relate T-Shirt sizing with Story sizing to mark the relative difference between user story size, e.g., Extra Small , Small, Medium, Large, Extra Large etc, We will discuss about story points in details, later in this article.
The below diagram will help you under stand story level estimation and Task level estimation.
Task estimations are not always followed, Many Agile practices run their execution (sprint or iteration) with only Story points. Tasks are used for better planning and tracking.
The table below highlights the major difference between
Traditional estimation always focus on how much time it will take to complete the work hence the scope is always constant and Time and cost varies based on estimation. where in Agile we focus on what are the functionality we can complete with in the fixed time box. Explained this concept in a diagram below.
End of Section "How Agile estimation is different"
Influencing Factors of Story Point :
Story Points are the measurement unit to estimate the size of a user story, on the basis of its
Amount of work
Story Point in Fibonacci Series:
To Estimate the size or the story point, we map a numeric value, it does not matter what are the values, what is important is the relative deference.
Three stories having story point 1,2 and 3 is equivalent to having the story point as 10,20 and 30. however the industry standard and to keep the practice uniform with in, team, organization, or even in the Agile world we use the points in Fibonacci series i,e,. 1,2,3,5,8,13,21,…
Fibonacci series number have relative difference with each other to give a virtual difference on your estimation
Where story point 1 means: very easy development with no risk, complexity, dependencies and add “nice to have” business value
Where story point 13 means : significant amount of complexity, possibilities of risk or dependencies and High business value.
Any story appears to more than 13 points, we strongly recommend to break the story in smaller stories.
Uncertainty of Higher story point :
We always try break the story into smaller story for better estimation and visibility of its Risk, dependencies and technical aspects. But we need to keep in mind each story has to be potentially ship-able. We should not break a story on the basis of its task like Development in one story and testing in one story. Breaking a story means splitting of an expected functionality by two independent smaller functionality.
Higher the points means its increase the uncertainty of its completion in time, because it has bigger risk, dependencies, and other unknown facts.
Story Points Vs T-Shirt Sizing :
During Estimation, we need to think about all its aspects , Complexity, Business value , Risk, Dependency, Amount of work in development and testing etc, and take a judgement of its overall size to assign a story point.
Its may be sounding complicated, but once you will started doing it, you will find its a fun and exciting exercise to do an estimation.
To correlate your imagination to assign a story points of a user story, categorize the size bucket as T-Shirt size and map a story point from the Fibonacci series with that. Refer the picture for that mapping will help you understand how you can estimate a story point with a user story.
Relative Sizing :
As mentioned earlier, we do a relative sizing to bucket the user story with Story point, why relative sizing is easy, Refer the Picture.
From this picture, its very hard to measure the difference between the amount of water each container can contain, but its very easy to measure which container can contain more water and which container can contain less, that’s relative difference in size, that is what we do to measure story points.
Lets elaborate the above concept further :
From the picture below, lets assume we have four stories to estimate it’s story points, Keeping the above theory in mind we can estimate the story point like this as mentioned in the picture.
The wine glass we know is the smallest here, but there can be smaller container than this like tea cup, so lets give it small not extra small, from our map we know small is Story point 3.
On a similar fashion we estimate the glass as 5, water jar as 8 and aquarium as 13. Yes 13 not 21 or more because we know there can be many larger container from this.
Few points on Story Point:
- Estimating a story point needs the estimator to have depth knowledge of the domain, product, technology, potential risks , dependencies etc. will talk about the techniques to estimate a story point later in this article
- Don’t Relate Story Point with effort of work, if required we do the effort estimation on task level, Tasks are child of user story. The Value of Story point have no how related to development or testing effort.
- At the end of each sprint/Iteration, the completed/accepted story’s story points get credited to the team.
- Keeping story point as 0 is a good practice for story type as Spikes or Discovery Story, as it not adding any business value nor ship-able
- Average of total completed story points for 3/5 or even more sprints are called velocity of that team, Velocity is use to measure the sustainable pace and trends of teams.
End of Section "Understanding Story Point"
Planning Poker (with Video)
Planning poker is a technique to estimate the story point or size of a user story in software development industry using agile framework.
In this technique, The Team member Development team including Tester, Scrum Master, Product owner participate, and optionally any external technical or functional expert can join on invite. But Only the Development team member can estimate the user story, the development team can clarify any of their doubts.
As per the name “planning poker” the estimator use to contain sets of cards looks like a playing cards, have the number from Fibonacci series printed on each card. during expressing the story point each estimator shows the card to every one to cast their feeling as a size of the user story, The Scrum master then mutually take the most voted number and assign with the user story.
However if the team don’t have the story card handy, it will not stop them to estimate using this technique. Then can estimate by
- Using Poker Card (as discussed earlier)
- Simple Speak the number
- Raise their Fingers
- Smart phone app for planning poker
Normally the story point estimation take place during grooming session, and mark the story to groomed status once the story is estimated. And no further changes is advisable to that story.
Refer this video to understand how this techniques work.
Planning poker in distributed Agile Teams
We can estimate user story in a same technique, even when our team is distributed in different geographic location. Only difference is they are connected on telephone and live screen sharing like WebEx, blue jeans etc.
Too much difference between two points from different member
We always do voting to assign the most voted story point for a story, how ever if there is a big difference between any two voting, The Scrum master needs to intervene and ask the team member why one team member think its that high and another team member thinks its that low.
After the discussion once again with in the team, The Team conclude a final story point to assign.
Story Points estimation Vs Effort Estimation
Remember We don’t and should not relate Story Points and Efforts.
Story Point is to estimate the Story Size, Value, Complexity, Risk , Dependencies etc
Where Tasks are the child’s of user story is to estimate its efforts in Hour, for better planning and capacity Mapping
Complexity Bucket (with Video)
Using complexity bucket is another technique to estimate the story point for a user story.
This techniques is majorly used by calculating the technical aspects of the story, by creating matrix of Areas of Complexity and Levels of complexity, and Aggregate the matrix values to get the story Point.
Refer the picture for your quick Reference, Or explore the video to understand how it works with a demonstration.
Quick Image Reference for Complexity Bucket estimation
Video of Details explanation and demonstration for Complexity Bucket Estimation
Watch this video to understand about Story Points
Watch the video to understand the Estimation technique of Planning Poker