Estimation of a User Story using Story points(SP)

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?

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. 

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 

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.

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.