Skip to main content

Estimation of a User Story using Story points(SP)

Last post 09:29 pm April 22, 2019 by Larry Blankenship
5 replies
03:59 pm April 20, 2019

Hello Everyone,

In our current project we are 6 developers and do absolute time based estimation i.e. 2 SP is one day and Sprint duration is 4 weeks(20 business days). So we plan approx. 200 SPs (according to calculation 240 = 2*20*6) with 40 SP with buffer. But we are noticing from last two Sprints that we are able to finish approximately 160 SPs and now the Product owner wants to know the reason for decrease in the output for the last Sprints as it is clear that even with buffer we should be able to achieve minimum or approximately 200 SPs. How do i handle it?

Secondly I am planning to move to relative based estimation using Fibonacci series. But my question would be how to take a reference Story i.e my 1 or 2 SP user story for relative estimation? I believe here again the reference User story will have to be estimated using time i.e. say this user story we need 2 days and there on estimate other relatively.

Thirdly and lastly we have the following structure for ticket formulation:

User story i.e. Feature ticket

- Sub task 1

- Sub task 2 

Currently with absolute time estimation we estimate sub tasks and sum up the SPs and update the major user story ticket with the sum. Is this a good option or are there any better way and also if i move to relative estimation how should i carry out the estimation for the above ticket structure.

 

Thank you and regards,

Vinay


06:44 pm April 20, 2019

Why is the Product Owner interested in the output of story points, rather than the outcome of a Sprint Goal being met?

Also, considering the issues you have described — including the false precision of absolute estimation and the reduced transparency that comes from using a buffer — why does the team believe that a velocity of 200 points ought to be realistic?


10:56 am April 22, 2019

Ian has raised good point there.

I would just like to add- : The whole mess is getting created because of your way of estimation.

Let's say you have 3 stories in product backlog. Decide which one is of medium COMPLEXITY.  Assign it 3 story points. So,

1= Very simple (Usually can be completed in few hours)

2= Simple ( Can be completed in a day)

3= Medium complexity

5= high complexity

If you follow this method, after one or two sprints you will get to know how many story points your team is able to complete.

Hope this helps.

Do not assign hours to tasks and then come to conclusion of story points. That's a wrong practice. 


Anonymous
04:32 pm April 22, 2019

All good points

What I found in story pointing is that sometimes the idea of how long a story will take to complete dominates the estimation.  What I like to do is break it down into 3 questions with the focus on the fact that a story should not exceed 1 Sprint

1.  What is needed for the story?  IE Database, services, dependences

2.  Is there Technical Debt? IE: Refactoring

3.  Is there a Spike? IE: Functional or Technical 

These questions will expand the conversation into another level allowing for a more confident estimation. Over time a team will be able to refine their velocity when they enter the storming phase. I like to use this formula.

(Time * Difficulty)/Weeks in Sprint = Story Points Rounds Up (Fibonacci)

(1 day * 5 (out of 10))/2 = 2.5 (3 Points)

(5 days * 3)/ 2 = 7.5 (8 Points)

(7 days * 6)/2 = 21 points 


04:48 pm April 22, 2019

In our current project we are 6 developers and do absolute time based estimation ...

In my 30+ years of software development I have never known anyone (including myself) to be able to do an "absolute time based estimation" with any level of reliability.  The fact that you included "estimation" in that phrase shows a level of uncertainty.  

But we are noticing from last two Sprints that we are able to finish approximately 160 SPs and now the Product owner wants to know the reason for decrease in the output for the last Sprints ...

This is proof that all you can provide is an estimate (read it as an educated guess) based on what you know at the time of the estimate and your past experience with similar work (empiricism explains this). Based on things you discover as you go, it may become easier or more complex. 

As for your questions #2 and #3 I suggest this.

  • Have the Development Team review "Done" items from your last 2 Sprints as one big body of work. 
  • Go through those items and let them rank them in terms of the actual work that they did ignoring their previous estimates.
  • View the list and have them determine groupings of "like" items.
  • Have them assign Fibonacci numbers to the groups based on their decisions.
  • Go to your current Product Backlog and start evaluating the work that has been completed based upon their assessments of the work already done. 
  • Provide Fibonacci estimates based on the relation to their completed work.

 


09:29 pm April 22, 2019

The thing to remember, is that story points are useful up to the point that actual work is being done. After that they rapidly lose any benefit, at least in my opinion. Mike Cohn suggests using story points to identify relative complexity between stories, but once the story gets to the point of deciding how to implement it, it's much better to estimate the tasks in hours or limit tasks to a day or less of effort.



There are a couple of benefits to this. When you estimate the tasks in hours, you can probably estimate much more quickly since you'll be doing it at a much more granular level. 2nd, you'll be able to identify if you're over your capacity for actual work that needs to be done.

The second part of this is that you continue to reestimate tasks every time you actually work against them.  Most tasks should be completed in the same day you start them.  If something isn't finished the same day you started it, you reestimate the time remaining, and it goes into the plan for the following day. This eliminates the 80% done for days on end issue that used to happen all the time during Waterfall projects.

Ideally, if a task isn't done the same day, you immediately recognize there's an impediment and take steps to remove them.

I've used this method and it's worked out pretty well in terms of balancing between identifying relative difficulty of the stories in the backlog and having a good sense of capacity for completing the work within the sprint.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.