The development team is the only one that commits to deliver a sprint. There are two common techniques used to reach a compromise. Both are guides a team can use to determine how much work to take on.
Capacity Driven
Capability-driven planning means that the team commits to what it can deliver in a sprint, based on evidence of how many task hours it thinks it can complete. They look at a buffer to account for meetings and downtime. They then add up the number of subtask hours in the sprint backlog and only commit to stories until their capacity is reached. This is useful for teams that don’t yet have a speed and I’ve seen it work for the duration of a project to great effect.
The key is to adjust the buffer based on hindsight. For example:
– In a two-week sprint there are nine 7.5-hour days (not including the planning day if meetings are all day). This is: 67.5 hours
– If we observe a margin of 1.5 hours per day (13.5 hours) to account for lunches and meetings. This results in 67.5 – 13.5 = 54 hours of a work sprint.
– Therefore, the team commits to no more than 54 hours of work in a sprint.
The buffer can expand or contract each sprint, and will soon hit a predictable number of hours that are wasted on scheduled meetings and other immovable impediments. Of course, this is not foolproof, but in my opinion it is very close.
speed driven
Velocity-driven planning means that the team commits to the number of stories they can deliver in a sprint based on empirical evidence of the number of story points they delivered per sprint up to that point. The number of story points per sprint is called the average speed. For example:
– The average speed of the team is 50 points per sprint
– They argue and think that before they were too ambitious and rushed the work, so they reduce slightly to 45 points (because they barely delivered the final story of five points in their last sprint).
The first three or four sprints are usually needed to establish a reliable speed, so if it’s their first sprint, they use their intuition as a team to pick stories.
Which is the best?
Both capacity-based and speed-based approaches can work, but I’ve found that speed-based planning tends to rely more on intuition during the first few sprints until the team is in full swing. Capacity-driven planning can lead teams to falsely believe that hour estimates are expected to be accurate (which they are not). I would recommend that capability-driven planning produces better results for new teams that haven’t sprinted together before, because the empirical evidence for task estimation is stronger, and it’s usually based on something everyone knows. of the team have made. I say this because velocity-driven planning is based on story points, whose relationship to time is less predictable in early sprints.
CLICK BELOW TO GET A FREE SCRUM EBOOK
