How to make perfect sprint planning
I have encountered a question in some forum related to sprint planning. The question was
How to ensure that there is a perfect sprint planning so that there will be no spill-overs to other sprints
In other words, how to ensure during sprint planning that no tasks will be carried forward to another sprints
Regards
In an environment that is full of uncertainty, ambiguity, and changes, what makes you think that a "perfect Sprint Planning" without ever having unfinished work is feasible or even necessary?
I'd also point out that, in Scrum, the team's commitment for the Sprint is to the Sprint Goal and not a specific scope of work to account for the fact that the scope of work may change as the team learns more about what is necessary and possible. The team can discover that some work that they thought was important and necessary is not truly necessary, as well as discovering new possibilities to add value to stakeholders.
For the purpose of my answer I am assuming that by "task" you mean the detailed description of every action that the Developers will be taking and that it is not the Product Backlog item that is being chosen to be included in the Sprint. If that assumption is wrong, then my answer won't do you much good.
Pick the Product Backlog items that the team feels they can complete in the current Sprint based upon the knowledge that they have. Task enough to cover the first day of the Sprint. Then every day during the Daily Scrum, the Developers can create enough tasks to get them through that day. That way only tasks that can be done are created and they are based upon the current knowledge of the team. It will also result in better tasks being created. If you create tasks at the beginning of the Sprint for the entire duration, you are creating those tasks at the point where you know the least about what work needs to be done.
I'd really like to know why you, or whoever posed the question, feels that there is such a thing as a "perfect sprint planning" and exactly what the criteria for that would be. Also interested in what forum you found that question.
In other words, how to ensure during sprint planning that no tasks will be carried forward to another sprints
That doesn't sound like perfect Sprint Planning to me. What a poverty of ambition it would be, if all people wanted was to saw through a given amount of work.
It would be more ambitious to frame and meet a valuable Sprint Goal by producing a Done increment, and thereby allow complexity to be better managed. Whether any work ends up being re-estimated on the Product Backlog for future Sprints is immaterial.
Though there is no silver bullet to make the planning so perfect that no spill over happens at end of sprint, Making sure that below inputs are 'Ready' will help to do sprint planning better way,
1. Prioritised, Refined, Estimated items in the Product backlog
2. Past sprint performance of the team(if known)
3. Available capacity for current sprint
And more importantly at the end of sprint planning, commitment from the team to Sprint goal.
Only people of Scrum team can participate in the sprint planning?
The scrum guide says - the scrum team may also invite other people to attend sprint planning to provide advice.
So, other people can also participate if they are attending to give advice. Is my understanding correct?
So, other people can also participate if they are attending to give advice. Is my understanding correct?
Yes, but not a manager who sits in every time to check what people do and say.
I feel this is a possibility that is added because it might be necessary somewhere some time. I can't think of a situation where an advisor would be needed during Sprint Planning. Would the time to get advice not be during Refinement and Sprint?
An example might be an architect who is not needed as a Developer, but who can provide counsel in Sprint Planning, perhaps advising about significant design decisions and overall technical direction.