With Scrum, careful Sprint planning is very important. It determines whether the following iteration cycle produces the desired result or chaos. How does one organise good planning?
I recommend the method proposed by Henrik Kniberg in his excellent book “Scrum and XP from the trenches“.
The basis for successful Sprint planning is a cleanly maintained Product Backlog.
“Cleanly maintained” means:
- It must exist!
- It must be up to date!
- The entries should be prioritised according to value.
Ideally each entry should also include a defined acceptance criterion, (“how to demo”). This guards against misunderstandings, e.g. concerning the scope of the entry. The Product Owner is responsible for the product backlog and must take it seriously!
With these prerequisites, the real planning can begin. One should take enough time on it. I advise one hour of planning for each week that the Sprint will take.
The results should be:
- The Sprint objective has been defined,
- The Sprint Backlog has been produced,
- The Sprint Review and daily status meetings have been scheduled (dates and times),
- A list of team members and their availability has been produced.
The first part is to choose the right Product Backlog entries for the next Sprint. Since the entries are in order of value, this is fairly easy.
One starts at the top of the list and takes as many entries as can probably be completed in one iteration. How many is that? One estimates the work involved in each entry taking account of experience with previous iteration cycles. Don’t keep underestimating the work! This technique is known as “yesterday’s weather”.
Of course, relevant experience of iterations is not always available. In that case resources can be calculated in terms of Man days available for the Sprint. For a 4 week Sprint with 5 people in the team, this looks like the following:
- Adam: 20 Man days
- Bertram: 18 Man days (will have 2 days holiday)
- Charles: 20 Man days
- Dora: 10 Man days (she works half-time)
- Edward: 20 Man days
This gives a total of 88 Man days. So should one plan for entries totalling 88 Story Points in the Sprint? No, because Story Points are estimated in units of “ideal Man days”. Such an ideal Man day is a day when the person works productively the whole time, without any pause, interruption, or illness. This does not often happen in the real world. So in practice less can be achieved. The ratio of ideal to real resources is known as the “Focus factor”.
So the planned Story Points in a Sprint should be [sum of Man days] x [Focus factor]. The Focus factor can be calculated from the previous Sprint using the formula.
Focus factor = [implemented Story Points] / [Man days used]
It is even better to average over many previous Sprints.
Suppose the previous Sprint managed Stories with total value 60 Story Points, using 90 Man days. The calculated Focus factor is then 60/90 = 0.66.
For the next Sprint, we should then plan entries totalling 88 * 0.66 = 58 Story Points.
For the first Sprint, perhaps we cannot thus calculate a Focus factor. One can then look round the firm for a team working in a comparable situation, and try to judge what their Focus factor is. If that does not work, one must just guess a factor. This sounds unprofessional, but after all it only happens in the first Sprint. Henrik Kniberg’s book “Scrum and XP from the trenches” recommends a factor about 0.7, which fits our experience too. So you can use this.
The Focus factor is useful not only when planning a new Sprint. It shows up the effects of all “environmental” problems. So it can be used to pressure the Product Owner to eliminate problems that hinder the Team from day to day. What if in midsummer the air-conditioning keeps failing or if there are often network problems? Both would reduce the Focus factor and have a direct negative effect on the project success. Eliminating these problems will increase the Focus factor, and so also increase the number of Story Points that can be implemented in a Sprint.
So now we know how we should plan the Story Points for the next Sprint. But before this can give the list of functions, all the relevant entries in the Product Backlog must be estimated. The method that we always use for this is known as “Planning Poker”. I explain how that works in my next article.
Loading ...