The entire sprint team work together and plan for next sprint goals. The sprint planning meeting is attended by the scrum master, product owner and rest of the Scrum team. The other teams may be invited on a need basis.

The PO ensures product backlog priority is up to date (At least top level items) for the team to pick up items from the product backlog. The stories are picked up and prioritized. The PO usually talks about sprint goal and once that is finalized, the stories are being picked up to for grooming.

For each story, product owner writes down the description of story and acceptance criteria. While grooming it can be further updated by PO and team. The team gets answers for their queries from PO with respect to functional expectations. In addition to that team work together to identify dependencies, constraints and nonfunctional requirements. The team typically elaborate more on functional requirements as well. The stories are broken down into multiple tasks.

All the groomed stories are then estimated by the team. Each story is tagged with story point or hours. The task usually is tagged with planned hours. The scrum master and team look at the velocity and capacity of the team and commit the amount of work which can be delivered in sprint.

At the end of this meeting, the scrum team would have two artifacts ready

Sprint Goal

Sprint Backlog

Best Practices

I always suggest the team go with pre-grooming. Typically planning happens a day before or when we are about to start a sprint. Understanding every story the first time, grooming, tasking and estimating take too much of time. Due to time constraints, it is not very effective and done half-heartedly. Moreover, all the questions can’t be answered upfront. This is one of the main cause of sprint failures in most projects as you are not sure of what you are committing. One of a good idea is to keep looking at upcoming stories and clarify all the doubts with PO or other stakeholders in advance. Spending 30 minutes to an hour by few folks in team 4-5 days in the previous sprint helps to do much better for next sprint. With this, the planning meeting will have just three goals

Explain everyone expectations from stories and get aligned

Estimate

Once #1 and #2 are done for all the stories, commit sprint.

Note: Many times, the business and competition demand last minute priority work to be picked when you start the Sprint. This is fine as long as it’s minimal.

PO shouldn’t be telling how much of work team should be picking. The team should take a wise decision by looking at previous sprint capacity. The idea is to have sprint success and continuous improvement.

A lot of teams prefer to keep 20% time aside to deal with tech debts. This may be a good idea while I always suggest the team to plan for this 20% during sprint planning and grooming only. What you plan is what can be accomplished.

Don’t be very aggressive as the quality of software in most cases is more important over quantity.

The team member shouldn’t be picking up multiple stories in advance. Each and every member should pick one story and once done they should move to the next one as per the priority order specified in Sprint. The exception to picking up the items within Sprint should be ok as long as PO is good with that.

Always create a task for stories. Don’t just include tasks which have business values while do consider tasks related to development and testing. For instance testing, code reviews, writing tests etc. Keep in mind, don’t write too many tasks.

Try to break down the story to as small as possible while if the estimation is going beyond then it’s important to divide that into smaller stories. There are instances where you can’t break down the story to the level where you are not getting business value out of it which is OK at a times but do avoid this situation as much as possible.

The story where lots of research is involved and there are unknowns which need to be unearthed, prefer to go with Spike.

Trust each other and support each other.

Pair when needed while do not work on the same task in series unless absolutely necessary. I have seen with the offshore-onshore model, the story is being worked on one story at offshore and further, it is handed off to another team member at onshore. These cycles keep repeating. The amount of productivity loss happens in this approach is not worth it.

Important Tip – The scope creep can be managed within Sprint with only two ways

Refuse new work in the middle of Sprint and take up that in next Sprint.

If it’s absolutely mandatory to pick the work in the middle, you need to take out an equal amount of work from Sprint.

At times, you are done with Sprint in advance, in that case, you can pick more work while it is always better idea to increase your velocity and focus on tech debts, testing, and quality practices. You can even spend time on learning which is usually way more important than we usually think