Subtask estimation vs Story estimation? What?

how do you know how to allot resources without going to this level of detail?

In Scrum, we don't. We have teams who self-manage these things from the get-go. Work is understood to be complex and emergent. Team members will therefore agree and commit to an achievable Sprint Goal, but not to the forecast of work. You are attempting to have a more predictive set-up, where managers try to lay things out and divvy things up.

My sprints contain stories, most of which are parts of larger epics. These stories are laid out with user stories, acceptance criteria and other standard info so everyone has full understand of who what when where and why.

A story, traditionally, is a placeholder for a conversation between the team and stakeholders. With electronic tooling, it has become possible to evolve a single representation from that placeholder to contain all of the emerging details through those conversations. However, what you describe here, with laying out user stories and standardization of information, appears to be more of an attempt to use stories as an alternative format for a requirements specification.

Within the stories there are subtasks. some are for frontend team and some are for backend. I have the product managers spec out the stories so they are ready for developers to create these subtasks - what needs to be done to satisfy the story.

This is another example of a lack of collaboration and conversation. Are customers, users, or appropriate representatives involved with working with the product managers to have conversations about the stories? Are the developers involved before they start decomposing the work to help split stories, identify technical dependencies, or even ask questions to get a deeper understanding of the work?

I have development managers(both front and backend together) lay out the subtasks needed to satisfy the story. these are then weighted using points in a planning poker session.

If the development managers are defining the subtasks, where are the developers who are actually going to be doing the work?

1 point is a half day, 2 for one whole day of work. these points bubble up from all subtasks and give the overall story a weight.

Why are you using user stories if you're going to equate them with time? If you're going to equate user stories to time, you might as well just use time. There's nothing wrong with estimating in ideal hours, for example, as long as everyone using those estimates understands exactly what an "ideal hour" means and how to mitigate risks.

We then divvy up subtasks across the development team based off the estimates, so we know how much work they all have, which is supposed to prevent overload on the sprint. example: 10 developer across 4 weeks of development would be 10 points per dev per week x 4 weeks = 40 points per dev, 400 for the whole team. The sprint never has more than 40 points assigned to a dev and the total is never more than 400. Testing not included.

Who divvys up the subtasks? Do the development managers push the work to the developers or do the developers self-organize around the work?

Based on the earlier definition of story points and the allocation example, each developer is at 100% capacity. There is no slack for the unexpected. How do you account for the unexpected? This could be unplanned work or unplanned absences, as two examples.

My question here is, how on earth does anyone weigh a story if multiple developers have pieces to do on the same story? What does weighing the story even accomplish? Over here we want to know what we can commit to in a sprint so we can project out what we can deliver. There is always a front and back end piece to almost every story we do, and separating that out between stories wouldn't be indicative of a real story would it?

One problem is that no one person can estimate a story, or any other unit of work. The best people to estimate the work are the people who are going to be doing that work. Collaborative estimation sessions where everyone can talk through the work and ask questions to ensure equal understanding is one of the best options. This isn't anything new, either - wideband delphi has been around and in use since the 1950s.

Committing to a body of work instead of a stakeholder-centric value-based goal runs the risk of turning the team into a feature factory. The team becomes isolated from the problems that they are solving. Again, this is nothing new. People like W. Edwards Deming have been talking about value and purpose and their affect on quality for decades.

It seems like the approach that you are taking is based on more traditional, plan-based, command-and-control methods of organizing work. The practices that you're trying to use are based on a more collaborative, adaptive approach. There are fundamental disconnects that are preventing you from taking full advantage of the practices.

Thanks so much for the reply Thomas and taking the time to shed some light here. Very much appreciated.

Hi Mike, as Thomas said above don't relate story points with time. Be it day or week or whatever. 

In our project we do task breakdown to understand approximately how much time it will take to complete story. Then we compare time, complexity , efforts of that story with some other story on which we have already worked. This way we do relative estimation. 

For ex: This story seems to be double complex than "the known" story. So, it should have double story points.

My question here is, how on earth does anyone weigh a story if multiple developers have pieces to do on the same story? What does weighing the story even accomplish?

Your experience will tell you the answer. How many story points your story on an average complete with full capacity of team members? Then if you have say half capacity this sprint, you can take up half story points for this sprint. It's as simple as that. Still if you have any doubts feel free to ask.

Is velocity and sizing required by your management?

When I've stood up Scrum, I've established that I would not use sizing unless it was mandated by those who were paying me. I would simply ask the developers, "how many PBIs can you fit into a one week Sprint?" They would tell me and I would move on.

I once sat in a Sprint Planning where the developers argued whether a PBI was 3 or 5 points. For 30 minutes. For one PBI.