What is Agile Estimation ?

(Scope of our this article to cover estimating user story)

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.

Agile 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.

How Agile estimation is different?

How estimation of a user story is different than traditional effort estimation, Traditional Estimation Vs Agile Estimation

The table below highlights the major difference between

Traditional Estimation

Agile Estimation

Primarily estimation on tasks takes place to get the timeline of the project.

Estimate the size of story for its value and complexity, task estimation is secondary.

Estimate to get the time line to complete the entire product

Estimate to plan how much business value we can deliver in a single sprint or iteration duration (typically 2 to 3 weeks)

We estimate development, Testing and other effort separately for any functionality

Estimate the size of a story keeping in mind, its development, testing, or any other activity to complete the functionality. However if required, we can estimate different tasks for independent resource specific efforts.

We estimate absolute values in Hours or Days

We estimate Relative sizing, learn more about relative sizing in our next section of understanding story point.

Estimate Before the development start

Estimate between the development for upcoming Stories of future iteration, by applying lessons learned from past sprints

Estimates to create Plan of schedule, and the development is plan driven

Estimates to Identify Value, and the development is value driven

Estimates of absolute number of time,  have high chances to miss the estimate.

Estimates to Identify Value in a range in Fibonacci number, have very less chances to deviate from the estimated business value.

Panels of technical Experts, Architects and other member involves to estimate.

The Agile Team, mainly Developers and Testers do the estimation collaboratively, with presence of Product owner or business analyst & Scrum Master. The Team may seeks input from external Technical or functional experts, but the estimation always own by the team.

Traditional Estimation Vs Agile Estimation for User Story
Agile Estimation for User Story

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.

Estimation-Time-cost-scope Traditional Vs Agile Estimation for User Story

End of Section "How Agile estimation is different"

Understanding Story Points

Influencing Factors of Story Point :

Story Points are the measurement unit to estimate the size of a user story, on the basis of its

  1. Business Value
  2. Complexity
  3. Risks
  4. Dependencies
  5. Amount of work
Story Points for Agile Estimation for User Story
Fibonacci Series Number in Agile Estimation for User Story

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.

Uncertenity in Agile Estimation for User Story
Agile Estimation for User Story

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.

Agile Estimation for User Story

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.

Agile Estimation for User Story

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"

Agile Estimation Techniques for user story

Commonly used techniques to estimate a user story

There are many estimation techniques for User Story, like Delphi, Wide Band Delphi, Complexity Bucket, Planning Poker etc. We will discuss two most commonly used techniques in software development industry those are

  1. Planning Poker

  2. Complexity Bucket

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

  1.  Using Poker Card (as discussed earlier)
  2. Simple Speak the number
  3. Raise their Fingers
  4. 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.

Agile Estimation using Complexity Bucket
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

End of Article

Hope this page was able to provide the information you were looking for, In case we missed something, feel free to leave your comments, feedback and suggestions, at bottom of the page’s comment section.

Author(s) of this article


  1. Hi Niladri,

    Thanks a lot for your hard work in preparing these tutorials, I really liked so far all your tutorials and vidoes.
    Is there any way that you can share the excel tools that you have prepared and used here e.g. Capacity planning, Agile estimation etc.

    Would be great help if you can share with me these great excel tools.

    Thanks & Regards,

  2. Hello,

    Thank you so much for wonderful video tutorial. I have doubt to calculative story points.

    I have below categories in my complexity bucket.
    Requirements – 2
    Design – 1
    Database – 3
    Development – 5
    QA – Manual – 3
    Automation Testing – 5

    Now total points will be 19 and it should go in nearest serious like 18 user stories. => Is the calculation right? If we add few more calories then user points will keep increase. I believe am missing some calculation like average. Can you please help me?

    • I actually did not got the question. Can you please drop a mail at support@agiledigest.com. Remember Requirements should not be part of your estimation. If you are estimation using Complexity Bucket then don’t sum them up. Complexity Bucket was an old technique. Now majority of the industry practice is doing Planning Poker for story Point estimation.

Leave a Reply

Your email address will not be published. Required fields are marked *


Post comment