I am no scrum aficionado and only have roughly a year of practical experience. So the following is to be read with a grain of salt.
I see several red flags in what you write:
5 hours sprint planning
This is way too long for a one week sprint.
The goal of the sprint planning is AFAIR to
- enable the team knowing what the current priorities are and
- to develop a battle plan for the upcoming sprint.
In order to do do this effectively, each side has to understand the
Product Backlog items.
In order to understand the
Product Backlog items the backlog has to be in good shape.
In the concrete planning phase, the
Product Backlog items are transformed into
Sprint Backlog items.
One possible cause is, that these items are not clarified / refined enough.
Another possible cause is, that the items are way too complex and leave room for too much interpretation.
Discuss very detailed in sprint planning
As said above, the discussion phase will be shorter, when the items are more concrete.
On the other hand: Sprint planning expects professional behaviour from every participant. This includes avoiding bikeshedding discussions.
Perhaps things are clear, but somebody starts a bikeshedding discussion.
More: Avoid discussions about implementation details. Although every idea ends up in code at some point in time, it is not the point of the sprint planning discussing, whether a simple array will do the trick, or it will be better using a linked list.
As most of team members are not senior
In scrum there is no distinction between senior and junior. Both are just developers. And this is a good starting point, which helps you keeping your discussion focussed on a viable solution backed by the better arguments and not the paycheck.
Mistakes of implementation and redesign during sprint
There seems to be a fundamental problem in requirements gathering, followed by a very vague product backlog.
As I said above: As long as the
Product Backlog is in a good shape, it should be hard to miss the point.
I can not imagine a situation like:
»As a user I want to see a handful of customers!«
»Oh, you didn't mean every of our 2 million customers?«
OTOH: What does in this context redesign mean?
If a developer chose a slow performing algorithm, then there is the next goal clear: choose a better performing one. But that is no "redesign", this is an optimization.
To your main questions:
How to deal with this?
It is trivial to mention, but I do it anyways: Do not forget, that you are dealing with humans.
It is very hard to have a group of different minds, which are able to share common concepts (like in Rashomon). In order to deal effectively with this, use as much redundancy in your communication as possible: e.g. explain the context of the item extensive, even if everybody "should know" what to do. Ask questions, whether everybody gets what the topic of a given item is.
If you are playing planning poker a good indicator, whether the understanding is good enough, is, that tasks are rated low. Low means low complexity means easy to understand and hard to miss.
One side-effect of iterating is, that the numbers for certain tasks will go up (because the team has an understanding of its capabilities and the hidden complexities). Then there is chance to break down the item into several less complex items with lower complexity.
How much detail should I discuss during planning to fit 2 hours long per a week sprint?
Salomonic answer: As less as possible and as much as necessary, but not more.
Choose an easy language (if it helps, use simple english or
ELI5) to avoid misunderstandings
Improve requirements gathering
Increase confidence of team members in their individual capabilities as well as their capabilities as a team
Improve personal discipline
Perhaps use fixed timeboxes for every item to discuss
Strengthen the position of the
scrum master to moderate effectively.