What is Agile Estimation ?

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

[ps2id id=’WHATIS’ target=”/]

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 ([ps2id url=’https://alumni.agiledigest.com/agile-digest-tutorial/user-story/#Hierarchy’ offset=’120′] read about story hierarchy [/ps2id]), 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

[ps2id id=’HOW’ target=”/]

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

[ps2id id=’STORYPOINT’ target=”/]

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

    [ps2id id=’PP’ target=”/]

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

[ps2id id=’CB’ target=”/]

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 [email protected] 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.

  3. Hi,
    1. is there a linear relationship between story points? A story with 3 points is three times complex than 1 point story?
    2. sprint1 of 30 points(15 stories * 2 sp) has 150 hrs of work estimation, sprint2 of 30 points(10 stories * 3 sp) has 300 hrs of work estimation. if we have 150 hrs of capacity. how can sprint velocity give a right estimate? it will fluctuate wildly.

    • Hello Alok,
      1. We don’t make such kind of calculative relation, Story Points not only just complexity, its also depend on Risks, Dependencies amount of work. The relative sizing is in-terms of bigger or smaller, more complex or less complex etc.
      2. Yes If this is the case your velocity will fluctuate. But practically it does not happen. if you estimate the story points keeping all its associate aspects like, dependencies, Risks, Amount of work, Complexity etc, you may find these 3 story pointers as 5.
      Secondly If you keep changing the team members with in team your velocity will fluctuate, as the new team members need more time. Try to keep the team constant as long s possible
      another example can be if your committing to some work that needs new technology or on New functionality or new Team members it will take more time than your previous works.
      Remember when you are estimation story points, If any area is uncertain and need to commit it, the story point will be high. Estimate it based on What you know and how much you don’t know.

  4. Hi Niladri,

    Am Nada Jonidi am calling from Syria
    very very valuable demo

    I’d like to ask you about the relation between story size and estimating ,I’m not sure if I got the idea correctly as the following

    first we need size estimating for sprint fitting
    second we to split if needed
    third we need re-estimating of those new stories
    after that we need to do time estimating

    thanks and my best regards

    • Hi Nada,

      Thanks for reaching us.
      When we talk about size, its story point, we do it during grooming or at least before sprint planning. This sizing we do on Fibonacci series like 1,2,3,5, 8. If the size is going too big like 13 or 21 we split the story to smaller stories, so that we can size it on smaller number. So for example if we split 1 large story to 3 smaller stories, we need to estimate all the new three stories.

      Time estimate is estimated as effort on tasks. Each story can have multiple tasks like Development, Testing, Review etc.

      Hope this answer your question

      Best Regards
      Agile Digest

  5. Hi Niladri,

    hats off to you …u have done tremendous job … it clearly shows your hard word and dedication … I really loved going through each and every single line you wrote .

    Would it be possible for you to create a session for “How to estimate budget planning in Agile scrum project? How the contract will be signed and what will be the duration of that contract as well as how the payment will be made from client ?”

    I have been asked this question in interview lately.

    Waiting for your reply .

    • Hi Anu,
      Thank you for this comment.
      Yes I can defiantly talk about “Agile Contracts” in details and how to construct it. You can drop us a mail at [email protected], with little more details. As from this limited information in this comment, I am unable to visualize the exact need.

      Best Regards
      Niladri, Agile Digest

  6. Hi all,
    Thanks for the amazing article it is very helpful. I have a question regarding factors influencing sizing . We have Business Value and Complexity as two factors however i see them as one factor not two , am i correct ? if not can you elaborate the difference more and how the developers will be able to judge it?

Leave a Reply