Should total spent hours for sub-tasks of User story 8 pts have to be greater total spent hours for sub-tasks of User story 5 pts

Hi Vinh, I can speak from a Scrum Master's point of view here. I have a team of young developers and we find it difficult to estimate the work effort. So, this is what we do as a team:

1) Using task estimates to estimate story points:

    1 day= 6 working hours

    6 working hours= 1 story point

You can do the math on how much an 8-Pointer will take vs a 5-pointer US. 

2) What I mentioned above answers your second question, 6 hours burned per user story point. 

Also, as a best practice- user stories are always estimated in points and tasks in hours. I tried this approach for 3 sprints to come up with my team velocity. 

Hope this helps! Feel free to ask questions if you have. 

Thanks

Anuj 

if a User story 8pts, total spent hour of its sub-tasks have to be greater or equal total spent hours for sub-tasks of User story 5 pts as always.

Not necessarily, because the complexity and effort of the story might also be considered in the estimate, and not just time.

From my understanding, I don't think it always correct as some times, we underestimate the story because limited understanding at that time.(not re-estimate point as it's best practice so the team can improve estimation next sprint planning or not change history as we used it to compare relative size...)

What's your thought on it ?

Work should be re-estimated on an ongoing basis so the team has an up-to-date forecast of how much is thought to remain.

2. Also he wants to know how many hours per story point we burned.

Why? What use is that information to him? The value he receives will lie in the increments received, not in the team’s estimates or burn rates.

  1 day= 6 working hours

    6 working hours= 1 story point

Anuj,

I would just ask why you are even using story points, if you're already converting them to a time equivalent.   Why not just use hours?   In your example, story point estimation is simply wasted effort.

Relative Estimation is about roughly sizing items, whether story points are used, or t-shirt sizes, or any other type of measurement (cars, animals, countries, etc).   Think in terms of extra-large, large, medium, small, and extra-small, and then just place each item in the category that it most closely resembles.

Vinh,

It is very important to communicate that estimation is for planning purposes only, and using story points in any way to gauge team productivity or throughput is a misguided practice.   Your manager should be concerned about measuring the value being produced by the teams, not trying to equate a time value to story points.

>> Also he wants to know how many hours per story point we burned.

Ask your customer this: what if the team burned down story points so efficiently that it exceeded his wildest dreams, yet the customer found no value in the product delivered?  Would it then matter?

Whatever size is given to items, and irrespective of the unit used, it is an estimate.

We are talking about complex work being carried out by humans. So estimates will often be at least slightly wrong. Occasionally estimates will be very wrong.

One of the main advantages of a Sprint is that such risk is limited by the length of the Sprint, and in a worst case, a decision can be made at the end of a Sprint to stop working on an initiative, if it looks like the cost is too high.

If teams are working towards a clear goal, and measuring their progress throughout the Sprint, such risks could be highlighted even sooner.

To add to the very good points above, here are my thoughts:

"One of my client challenged me about this question and they really think that if a User story 8pts, total spent hour of its sub-tasks have to be greater or equal total spent hours for sub-tasks of User story 5 pts as always." I'd suggest a series of talks with your client during which you can hear their concerns (likely cost and time), understand where they're coming from and then explain the way software development works, how unknowns and uncertainties are contained, how things get built, and the impossibility to accurately predict development effort; following which you could explain the A to Z of Scrum.

But then again, it depends on how difficult the client is. On how much they know about software development - SDLC may be an unknown to them. On how open they are about their plans and desires (is the PO on site or remote, with the customer?). On how much they're willing to invest. On how open they are to communicate with you. And so on

"Also he wants to know how many hours per story point we burned." Nonsense. Do I feel a project manager as client's representative? Likely. How about you and the PO explain to him he should be concerned about value for the business not a spreadsheet with logged hours or story points "completed". Value resides in the increment released to production, not in burndown charts to be circulated around.