What happens when timebox expires?

1. Do nothing in the moment, let the team end the meeting. Later, coach the team on the importance of starting and ending the meetings on time, as it really is in their best interests.
2. The team is responsible to deliver the sprint goal as agreed in sprint planning. Each member is committed to that goal and is expected to deliver tasks as time and skill allows, all directed to complete the sprint goal. They may not always pick the most efficient way through, but it is their decision. If you notice a team member not volunteering for tasks, then they should be coached, on the side, by the Scrum Master.
3. Discuss directly with Product Owner; as they alone make the decision.

Yes, it does make for an uneasy feeling when we are coming from the traditional PM/waterfall world. Maybe even a sense of not doing our job when we "leave it to the Team," or to the Product Owner to decide. I think that's where the true value of the Scrum Master comes in ... how to be patient and coach the team through situations and obstacles while respecting their "sovereignty."

> 1) What should the ScrumMaster do, if the timebox for the Sprint Planning meeting
> expires...how we can end the meeting and continue without a properly settled down plan

By the end of Sprint Planning the Development Team should have enough of a plan (i.e. a Sprint Backlog) in place to allow them to start development without delay. Planning and replanning can and should continue afterwards, because no plan is ever assumed to be complete and then frozen.

Of course, the more complete a team's Sprint Backlog, the better positioned they will be to assess the work remaining. That's why a team should aim to make their forecast as complete as possible within the Sprint Planning timebox - it will help to establish transparency from the outset.

> 2) The concept of not assigning tasks in the Sprint planning meeting(i.e `Self organizing teams`) is
> very hard to digest for me...How exactly can we expect people to volunteer for the tasks by
> themselves? How to avoid inefficient people in the team

It's a matter of professionalism. Scrum requires it from each and every person who performs their role. To be a bit more specific, the Scrum Team as a collective will require that professionalism, and will self-organize to attain it. The team will value transparency of the work done and how it is conducted, and it won't be afraid to inspect and adapt its working practices. The team will be committed to professionalism and improving it further.

> 3) There a some tasks inherently difficult to prove the worth in terms of business
> perspective (such a code refactoring). How to convince the Product Owner to
> prioritize such items in the Product Backlog

Don't. It isn't your job to convince the Product Owner of anything regarding product value. What you can do as another team member is to explain the likely impact on those things the PO does care about. Will throughput diminish as technical debt ramps up? Will the product become unmaintainable?

Also, bear in mind that the Development Team is responsible for quality of its work. If technical work (such as refactoring) is required to maintain the team's standards, then they are perfectly within their rights to reduce the scope of work they forecast for completion in the next Sprint Planning session and to perform those technical activities instead.

Some thoughts from me:
1)
- The team shoud plan the most valueable items (which also should be understood most) first. If timebox expires the remaining items should be less valuable. Just stop the meeting, discuss and pull more items during the sprint.
- If the team does enought backlog refinement, discussion in Sprint planning can be just a be confirmation that the item is well understood. Items which are discussed the first time in Sprint planning are always high risk.
2)
- I advice having a physical task board for the team. As a ScrumMaster foster active behaviour and do coaching.
3)
- Maybe try to plan with some slack and do continous refactoring. Refactoring can also be part of the DoD.

Thank you very much for the great responses.

hi, is slack allowed in Scrum? based on Scrum guide, next sprint starting after closing previous, but based on training manual, slack is allowed

many thanks

I'm unsure what training manual you are referring to (I would not refer to the Scrum Guide as a manual).

That said, I believe the slack you are referencing is capacity allowance within a sprint, instead of time in between sprints.

Slack within a sprint improves the Development Team's ability to meet their Sprint Goal, and allows for critical thinking and creativity to occur within a sprint, as opposed to working from a set lists of tasks.

A good analogy is your personal computer/laptop.   What happens when your computer is close to max capacity (95-100%)?   How does that performance compare to a computer operating at 60-70% capacity?

Is it preferable to have a Development Team plan a sprint according to their max capacity, or according to a capacity level that allows for unplanned events and discovery?

Another analogy is slack in the flow of traffic. If a road is filled with vehicles to maximum capacity, it is unlikely to flow well. You are more likely to encounter nose-to-tail traffic jams. Slack in the system typically helps to improve flow. Hence in Scrum, it is best not to aim for 100% utilization of team members, but rather to optimize flow so maximum value is delivered in a controlled and timely manner. To obtain sufficient slack, the amount of work undertaken in a Sprint should not lead to over-utilization and the consequent risk of bottlenecks. Sprints themselves run on-cadence and back-to-back without gaps or interruption.

The Sprint Retrospective seems to be the perfect venue to address #1 and #2.  If planning wasn't completed within the 8-hour time box, how can the team ensure they do complete it during future planning events?  If some team members were more productive than others, why was that and how can the team help those less productive to increase their productivity?  It shouldn't be a blame game, since that would be contrary to the Sprint values of openness and respect.  However, someone may need more training, practice, or intent clarified.  That someone also may not feel as though s/he is part of the group.

If a Development Team is coming together for the first time for the first Sprint, there's going to be the standard group dynamics and stages (Forming, Storming, Norming, Performing, Adjourning) which will affect their productivity as well.

A Good Product. Owner an factor in slack within the Sprint.   There is not Slack between sprints,  if a dev is on vaccation or sick, the sprint continues.. however PO needs to  consider this while creating the sprint log.