User Story Estimation

I think the most difficult and confusing step in Scrum is estimation. Since software development is combination of science and art and we are almost always developing something new , it becomes very hard to estimate efforts in Hrs. 

Estimating a USer story in Story points is better way of estimating things. If done properly, it saves lot of time/effors while negotiating with Product Owners on what stories should go in Sprint Backlog..

Instead of using a a tradionatial Fibonacci sequence for estimating user story points, It is better if we estimate  efforts by multiplying Size and complexity . It is easier to approximately estimate the size( for eg 2 days vs 5 days) and complexity .

I will be presenting various guidelines for estimating size and complexity. I will be showing you simple tools/methods to identify if your estimates are proper and their best practices.

5 favorite thumb_down thumb_up 9 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

What is estimation

Why estimation

How estimation

   1) Effort=Size * Complexity.

Guidelines for calculating Size

Guidelines for calculating Complexity.

Distribution of Efforts

How to calculate Vilocity

Learning Outcome

  • Proper estimation techniques.
  • Best practices for estimating.

Target Audience

Developments teams and Scrum Masters

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • AgileSattva Consulting LLP
    By AgileSattva Consulting LLP  ~  1 year ago
    reply Reply

    Estimation, is evolving process. So far, we have had many estimation techniques in traditional ways as well. As I understand  the very reason of getting Story Points is because human brains understands relativity very well rather than absolute (like who is shorter in a group is easier, and difficult to say that if the  person is alone). My only concern is giving a formula might defeat the purpose of bringing in relativity - would like you to emphasize "Relativity" while this could be a guideline. Would invite you to think about it

    Could you also share data from your experiences, as you mentioned that you have been using it and has worked for you?

  • Ram Srinivasan
    By Ram Srinivasan  ~  4 years ago
    reply Reply

    Hi Yogesh,


    Thanks for submitting a proposal. I am of the opinion that "estimating is useful, estimates are useless".  The process of estimating (by planning poker, say) brings about discussions on what needs to be done, and uncovers the shared understanding. Relative estimates, are, at best, a guess at the size of the story considering complexity, efforts, risk and uncertainty.

    On a different note, how exactly do you assign values (effort , complexity)? Just like planning poker? 

    One guess (story point) is as good as another guess (value x effort).  So I do not understand what problem this new approach solves.

    Can you please help me understand?



    • Yogesh
      By Yogesh  ~  4 years ago
      reply Reply

      Hello Ram/Deepak,

         Thanks for replying. Estimating efforts in hours is not easy and most of the time error prone. Reason for estimation in hrs to be error prone is that it depends of lot of factors, For example, in Dev team there are mix of people with different level of experience. Most probably, person with say 5 yrs of.NET exp will code a story in say 5 hours and same story can take about 10 hrs by a fresher. Moreover, if someone has earlier worked on same kind of problem, he is likely to take less time. Due to this in planning poker, it becomes very difficult to come to an agreement on exact hrs. Over a period of time , I have seen that people with more exp are only participating in planning poker which result in aggressive estimates and people with less exp burning mid night oil to meet deadlines.. L  

      Having said that, Suppose in our Planning Poker, instead of debating on number of hrs, if we say that on the size of this story is like few hrs or 1-2 days or 3-5 days, people will be able to relate to it more.

      and on complexity factor also, if we say a particular story is very straight forward, with no unknowns or R&D required and require very basic programing skills vs a bit complex, with some R&D required and good amount of programing skills required , it makes more sense. And people are able to relate more.

      and Effort of a story is simply multiplying Size with complexity. 

      By doing so , development teams can come to an agreement on effort fast. With more mature teams, this can start giving very accurate estimates.

      Please let me know if you need more info.




      • Sachin goel
        By Sachin goel  ~  4 years ago
        reply Reply

        Hi Yogesh,

        I am unsure how does estimation moving from HRS to DAYS help a lot. Using DAYS(also known as Person Days PD) you get into debate of how many effective hrs in the day etc. Furhter with story having long PD you may have additional complexity of managing relative completeness.




        • Yogesh
          By Yogesh  ~  3 years ago
          reply Reply

          Hello Sachin,

          You are getting it wrong. I never said that efforts will be in PDs..  Its not about person days... Buddy, Its about calculating velocty of scrum .. And velocty in terms of efforts ...

          I hope my proposal get selected and we can have a healty debate during my session :):)



  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Yogesh,

       Estimate is a slippery slope. Do you have any information / experiences showing this approach provides better results or discussion around stories?




    • Yogesh
      By Yogesh  ~  4 years ago
      reply Reply

      Hello Joel,

      First of all thanks for Comments.

      I have been using this technique in my projects from quite some time now and it has given me better estimates. Given more confidence to Product owner and development teams.

      Michael Lant who is a well known blogger on Agile and CEO at has explained almost similar approach on his website and has been  highly appreciated. 


      Please let me know if you need more insight.




      • Savita Pahuja
        By Savita Pahuja  ~  4 years ago
        reply Reply

        Yogesh, Are you going to talk same technique explained in the blog you mentioned.

        • Yogesh
          By Yogesh  ~  4 years ago
          reply Reply

          Yes savita.  I will be covering all these techniques and best practices