Estimation

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?

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.

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.  

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

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 scrum.org site.  You'll see some awesome ideas.  

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.

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.

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.