Skip to main content

Why both with points based estimation if you're doing capacity based sprint planning?

Last post 05:07 pm September 18, 2023 by Sumit Ambastha
5 replies
09:06 am September 15, 2023

If you use capacity based sprint planning i.e. looking at hours available and then estimating hours required for each ticket, and bringing in till you're at capacity. 

Then what is the point of estimating in story points when initially refining the tickets? As I understand it the main benefit of story points estimation is that they are an abstract measure of relative complexity, and overcomes the issue of everyone disagreeing with how long something will take (because of differing levels of skill/experience). Whereas easier for everyone to compare the ticket to another ticket and compare effort/complexity in relative terms.

But let's say you do that. When you come to your sprint planning session, you are going to ask everyone how long the ticket will take, and therefore you're going to run into that issue anyway. So why not just estimate in hours when you initially refine the ticket - and then sprint planning is just a review/ratification of the initial time estimate?

Am I missing something? I'm just not seeing the benefit of estimating in story points during refinement, and then capacity based sprint planning.

10:15 am September 15, 2023

you are going to ask everyone how long the ticket will take

Why? If the Developers have estimated using story points, why wouldn't an understanding of story point capacity be enough?

So why not just estimate in hours when you initially refine the ticket - and then sprint planning is just a review/ratification of the initial time estimate?

If the Developers actually find it easier to do so, then of course they can.

10:37 am September 15, 2023

Time or story points, there is no precision in these values if the work is complex. These are guesses that can be leveraged as a guide when Developers are pulling backlog items needed to achieve the Sprint Goal into their Sprint Backlog. 

The benefit of sizing during refinement can include the all important collaboration and conversation that occurs when Developers don't agree. This can result in better understanding of the work and improved readiness leading into Sprint Planning.

When you say "capacity based sprint planning" and "bringing in till you're at capacity" I wonder where the Sprint Goal fits within this. Is it important to "bring in" until Developers are at capacity, or is it more important to pull items needed for achieving the objective of the Sprint Goal? More items can be pulled in should the Sprint Goal be achieved. 

11:49 am September 15, 2023

"Capacity-based Sprint Planning" doesn't imply hours. Capacity is a measure of the amount of work that a team can achieve. Measuring velocity in story points and comparing the forecast availability of the team for the upcoming Sprint to availability in past Sprints is just as much capacity-based planning as estimating hours, measuring completed work in hours, tracking hours worked, and forecasting available hours. If you're not considering the capacity of the team to do work - whether it's in hours or a percentage or just a notional increase/decrease - I don't see how you can effectively plan a Sprint.

It seems like the question here is more about estimating in two different units. I would consider any and all estimation waste. Spending the team's time to estimate does not add value nor is it necessary to deliver value to end-customers. Such waste, to the extent possible, should be reduced or eliminated from the process. If estimating once is waste, spending the time to think about estimates twice (and in two different units, no less) is also waste.

03:57 pm September 15, 2023

I really like the differing opinions above.  I agree somewhat with all of them.  

I am not sure where you got your understanding of Story Points but this article by Ron Jeffries, who is said to have created them, might give you some better insights into the origins.  

There is nothing in the Scrum Guide that says you have to use any specific method to estimate the items that are in your Product Backlog. In fact, the word "estimate" or any variations of the word is not used in the Scrum Guide.  So anything that you have heard or read is something that people have found useful but it is not part of the Scrum framework. 

I have worked with teams that used Story Points, T-shirt sizing, hour estimates, colors (yes, they wanted to be different), no estimation at all, and other various techniques.  All of them were successful at delivering usable increments of value in every Sprint. 

You are correct that the practice you are using is wasteful.  So, bring it up in a Retrospective and let the team discuss it.  After all, your team is the only one that knows what is best for themselves. 

04:21 pm September 16, 2023

During my work with few corporates, the common practice what I have seen is to use number of hours while estimating the story. in my personal opinion, it is better estimation and helps to compare the stories/tasks in more uniformed way.

The basic idea is to arrive at the better way of estimation. If using the hours helps in estimation, I don't see any reason to not use this. This works well with the team and serves the purpose.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.