Skip to main content


Last post 05:04 pm March 20, 2024 by anil ahir
7 replies
02:30 pm July 5, 2022

while doing detail task breakdown, hours exceeds the capacity of the team. I think it's the issue of not accurately estimating story points.What are the best techniques to do proper estimation

04:08 pm July 5, 2022

There's nothing necessarily wrong with the story point estimates at all. Perhaps the Developers just need to take less work on during a Sprint, by reducing their capacity.

Are they under some sort of pressure to take on more work than they can realistically complete?

04:23 pm July 5, 2022

Depending on how the team defines story points, there may not be a way for them to equate story points with hours. If you can't equate story points with hours, then there may not be any issues when the team gets to more detailed task breakdowns and discovering that there is more previously unanticipated work. Even if the team can equate story points with hours, then the team should expect to learn more as they break down the work, since estimates of smaller things tend to be more accurate.

I wouldn't make this about how to do "proper estimation". I'd look at how you are refining the work and try to break down the work into smaller pieces earlier. This could mean vertical slicing into more Product Backlog Items, or it could mean starting to name the necessary tasks earlier. Both will help the team estimate and plan better.

06:32 pm July 5, 2022

I've said this many times in these forums.  Story Point estimation is nothing more than a guess based upon the information you have available at the time you make your guess.  Their use is limited to allowing Developers to put together a body of work that they estimate(i.e. guess) can be accomplished in a Sprint duration.  As soon as real work begins all of those estimates are useless.  Your example is actual proof of my position. 

I'm not going to add much more because @Ian and @Thomas have given you excellent advice already.  I will however leave this for you to read.  This is a post made by Ron Jeffries, the person said to have created Story Points.  It provides some background and advice that I think is pertinent to the situation you have.


02:37 pm July 8, 2022

It is best to use story points to discuss PBI complexity and eek out more information through conversations.  Then use flow metrics (monte carlo) to help forecast how much work will be pulled in (which is still an estimate).

There are a number of studies on story point versus actual effort and the correlation is really pretty bad.

Read up on Kanban on the site.  You'll see some awesome ideas.  

03:21 pm July 9, 2022

Story points are a personal and team unique measurement of complexity.

Complexity is based on the developers experience and knowledge within the BPI.

As a team storms and norms they begin to settle and story points begin to have a common boundary. For example, the developers guess within a similar value. Until this happens, you could limit the number of PBI, adding new items into the sprint when required.

You will see velocity settle over the past 3 sprints at 40 points, for example. If this is the case, this value is your "Hard Stop". Do not allow PBI items into the sprint that push this cap.

I've seen teams "fail" a sprint month after month. Each sprint they where given 80 points of work, had they NEVER hit 50 in 24 sprints. This kills the developer team and makes them feel like they are failing. It also indicates that the Scrum Master was not guiding the team into identifying and resolving the issue.

I recommend capping the Story Points to 80% of their 3 month average.

If the team complete the sprint early, then celebrate and have a great retro.

An interesting observation that I have found during 15 years of running Scrum-But..

If a Team who can achieve 50 points are given 80 points, they achieve 30 points

If a Team who can achieve 50 points are given 40 points, they achieve 55 points

The answer is very obvious once your see this in action.. try it out.

09:25 pm July 9, 2022

You are actually estimating twice.

Once in story points and once in hours. Skip the story points and estimate in hours. (Or estimate in story points and leave the hours.) But remember: nobody is always working. You'll talk about yesterdays sports, tv shows, the children, you'll get coffee, read the news, read emails, spend time in meetings and discussions. And you'll visit the facilities...

If the Developers work 40 hours/week, they will not do 40 hours of work in that week.

05:17 am March 20, 2024

As per my experience you can try this-

To improve estimation accuracy and avoid exceeding the team's capacity, consider the following techniques:-

1. Use Relative Sizing: Instead of estimating in hours, use relative sizing like story points. This approach helps focus on the complexity and effort relative to other tasks, rather than absolute time.

2. Planning Poker: This technique involves the team collectively estimating the effort for each task or user story. 

3. Reference Tasks: Keep a list of reference tasks with known story points and use them as a benchmark when estimating new tasks. 

4. Break Down Tasks: Break tasks into smaller, more manageable pieces. Smaller tasks are easier to estimate accurately than large, complex ones.

5. Include Buffer Time: Factor in buffer time for unexpected delays or additional work that may arise during the project.

6.Involve the Team: Ensure that the team members who will be doing the work are involved in the estimation process. 

By implementing these techniques, you can improve the accuracy of your estimations and avoid overloading the team's capacity.

i hope this will help you.

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.