Sprint Planning part 1: Selecting items for the Sprint Backlog
When backlog refinement and estimation is done before the Sprint Planning meeting and when the velocity of the team is known. Then what is the sense of the first part of the Sprint Planning meeting? The Sprint Backlog can be filled “automatically” as result of the velocity and the effort of the PBI’s, isn’t it?
unfortunately it is not that simple. Software development is a complex process and the velocity varies with many factors. Just to name a few:
- Who will be working on the Sprint Backlog?
- Has the Definition of Done changed?
- Are there any new or removed impediments?
- Are there scarce skills in the team?
- Technological and business coherence
A self-organizing team can intuitively give a good estimation based on previous velocity and the factors above. To my experience this estimation is much better than a calculated "capacity" based on the available man hours. The reason is that people vary in skills and velocity and there are complex social processes in a team.
> When backlog refinement and estimation is done before the Sprint Planning
> meeting and when the velocity of the team is known. Then what is the sense
> of the first part of the Sprint Planning meeting?
I look at it this way: backlog refinement and estimation, when done regularly and conscientiously, will allow Sprint Planning to go smoothly.
...and it's another opportunity to adapt. Furthermore it's important to ensure that there's a consensus due to prospective work for the next sprint. Sprint planning is your best chance to ensure that.