[ad_1]

The development team are the only ones that commit to delivering a sprint. There are two common techniques used to arrive at a commitment. Both of them are guides that a team can use to determine how much work to take on.

Capacity Driven

Capacity driven planning means that the team commit on what they can deliver in a sprint, based on evidence of the number of hours worth of tasks they think they can complete. They observe a buffer to account for meetings and downtime. They then total the number of hours of sub-tasks in the sprint backlog and only commit to stories till their capacity is reached. This is helpful for teams that do not yet have a velocity and I have seen it work for the duration of a project to great effect.

The key is in adjusting the buffer based on retrospective. For example:

– In a two-week sprint there are nine 7.5 hour days (not including planning day if meetings take all day). This is: 67.5 hours

– If we observe a buffer of 1.5 hours per day (13.5 hours) to account for lunch and meetings. This works out 67.5 – 13.5 = 54 hours a sprint for work.

– Therefore the team commit to no more than 54 hours of work in a sprint.

The buffer can be expanded or contracted each sprint, and you will soon reach a predictable number of hours that are lost to scheduled meetings and other immoveable impediments. This is of course not fool-proof, but it is very close in my opinion.

Velocity Driven

Velocity driven planning means that the team commit on how many stories they can deliver in a sprint based on empirical evidence of the amount of story points they delivered per sprint till that point. The number of story points per sprint is called the average velocity. For example:

– The team’s average velocity is 50 points per sprint

– They discuss and think that they were overly ambitious before and rushed the job, therefore they reduce slightly to 45 points (because they barely delivered the final five point story in their last sprint).

The first three to four sprints are usually needed to set a reliable velocity, therefore if it is their first sprint, they use their gut feeling as a team to pick stories.

Which one is best?

Both capacity driven and velocity driven approaches can work, but I have found that velocity driven planning tends to rely on gut feeling more for the first few sprints until the team are in full swing. Capacity driven planning can falsely make teams think that the hours estimates are expected to be accurate (which they are not). I would recommend that capacity driven planning yields better results for new teams who have not run a sprint together before, because the empirical evidence of task estimation is stronger and usually based on something everyone in the team has done. I say this because velocity driven planning is based on story points, whose relationship to time is less predictable in the early sprints.

CLICK BELOW FOR A FREE SCRUM EBOOK

[ad_2]

Source: http://ezinearticles.com/?Scrum:-Sprint-Planning:-Capacity-Driven-Versus-Velocity-Driven-Planning&id=7639961