The statements that you claim should be true in Scrum aren't necessarily true in Scrum, according to the Scrum Guide.
It is not true, according to Scrum, that you should be estimating user stories in story points. The Scrum Guide mentions neither user stories nor story points. In Scrum, you have a Product Backlog that contains Product Backlog Items, and one of the attributes of a Product Backlog Item may be a size. However, there are many ways to size Product Backlog Items, and a size doesn't even need to be a numerical value. The purpose of sizing or estimating is to enable the Product Owner to understand how much effort is likely to be required to complete work to properly order the Product Backlog and for the Developers to be able to effectively plan a Sprint by determining what Product Backlog Items can likely be completed in an iteration.
Scrum is silent on if the Developers should be assigning work or not during the Sprint Planning. The Scrum Team is self-organizing and self-managing, and the Scrum Guide does say that it is solely up to the Developmers to determine what they can achieve over the course of the Sprint and how it is done. The requirement is that, by the end of Sprint Planning, the team has done enough work to determine which Product Backlog Items they can likely achieve by the end of the Sprint timebox. Some teams prefer to assign out all of the work, at least tentatively. Other teams prefer to pull the work in as the Sprint progresses. Both are valid, and both have tradeoffs.
In Sprint Planning, you don't need to break down every single Product Backlog Item. You need to do sufficient breakdown of the work to ensure that you can take a subset of the Product Backlog and forecast that you can achieve the Sprint Goal. This work can be done throughout refinement activities that occur (there is no specific Scrum event for refinement) as well as at Sprint Planning. The act of placing estimates on Product Backlog Items is an outcome of refinement, which may be estimating in points, hours, or even no value and simply ensuring a nearly uniform size of Product Backlog Items.
Now, moving on to estimates. There are some good practices for estimating work in software development. One of those practices is not assuming that the work will be done by any particular person. Different people take different amounts of time to achieve something, simply based on their knowledge and the set of skills needed to do the work - not everyone is equal. You shouldn't be estimating work to be done by the expert on the team, since that person may not be the one doing the work. On the other hand, estimating as if the least skilled person is going to do the work would result in overestimating everything. So you need something in the middle. Techniques such as Wideband Delphi and Planning Poker are designed to help with this.
This is also one of the reasons why people tend to avoid estimating in hours. There are two considerations here. First, complexity is not likely to change based on who is doing the work. The work is equally complex, but some people have existing knowledge and skills that allow them to cut through some of the complexity. Second, if you estimate at the team level, complexity is also considering the team's effort. More complex stuff is more likely to include pair programming, more intensive peer reviews, more testing, and so on.
So, my recommendation is two-fold:
- Use consensus-based estimation techniques and risk management to determine what the right estimate is. Find something between the mid-point and the highest estimate, based on the level of risk that you are willing to accept in the estimate.
- Consider moving away from time-based estimates toward complexity-based estimates. Or, as an alternative, extremely small units of work that are all roughly equally sized.
