Skip to main content

Sprint Planning part 1: Selecting items for the Sprint Backlog

Last post 07:53 am January 18, 2020 by Piotr Górajek
6 replies
06:21 pm March 18, 2014

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?


04:14 am March 19, 2014

Hi Franck,
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.
Best, Ludwig


04:58 am March 19, 2014

> 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.


Anonymous
10:47 am March 19, 2014

...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.


12:10 pm January 17, 2020

It is not necessary that always Product Backlog would be 100% groomed with estimated stories. Sometimes, PO is doing prioritization and grooming sessions in the spring planning meeting also. ( In the sprint planning meeting, PO may remove or add  some new stories  based on customer requirements, business demand and last sprint status).

So, an automatic filling spring backlog is not suggestable. 

Team should pick stories one by one based on latest capacity planning ( available bandwidth of each team member )


05:03 pm January 17, 2020

Team should pick stories one by one based on latest capacity planning ( available bandwidth of each team member )

I was agreeing with you until the last sentence.  Sprint Planning is not about filling your team to capacity. It is about planning a body of work that will produce a valuable increment. If you fill to capacity, you have no ability to deal with the unknown. Also, how do you know how long an item will take to complete until you actually start working on it?  How often are people able to say exactly how long it will take to do something correctly before they even start the activity?  Can you say for certain that it would take you 2 hours to add 6 new plants to your garden?  Can you say it will take you exactly 2 hours to leave your home, go to the market, pick up a list of 9 items and return home?  This is why the original premise is flawed.  Plan your Sprints with a forecast of what it will take to produce an increment of valuable work, not based on a number that is nothing more than a guess. 


07:53 am January 18, 2020

@Franck van der Sluijs I have a few questions for you:

  • Does this approach ensure that goals are known?
  • Does this approach (at least at the beginning of the Sprint) allow us to forecast what we deemed necessary to achieve Sprint Goal and other goals that we might have, like those related to continuous improvement of our process?
  • How does it address this statement form Scrum Guide:
    • "(...) The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint. (...)"
  • Does "the first part" of the Sprint Planning event focuses on "filling capacity" or on creating shared understanding why we run this sprint, what goals we want to actually achieve?

@BHAVIN RANA as @Daniel Wilhite wrote, I also mostly agree with the first part of your comment, and I also don't agree with the last statement:

Team should pick stories one by one based on latest capacity planning ( available bandwidth of each team member )

This statement just simply treats Development Team members individually, like an independent cog, a resource that we need to utilize. This IMHO looks like some old-fashion PM BS that is unfit for complex problems that we try to address by empirical approach.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.