Incremental Release Planning

Release planning for a Scrum project can be a tricky proposition. The project’s stakeholders justifiably want some early predictability as to when individual releases are likely to be delivered. I frequently see teams attempt to accommodate this by tackling their project’s release planning in one big up-front meeting. Having one release planning session for a whole project’s deliverables can leave the team feeling that they have offered up no more than a very rough guess based on scant effort and consideration. The result can be a release plan that the team do not believe in.

For the last six months I have taken a different approach. Rather than having one big release planning session I have spread the exercise over several short sessions using a visual technique. I did not come up with the technique. A team member briefly described it to me in passing after attending a Scrum course with Martine Devos. I have added my own refinements over time to evolve those initial rough details into an effective working practise, the details of which I present in this post. In lieu of a better title I will refer to the technique as Incremental Release Planning (IRP).

The idea of IRP is to have several sessions, each of which plans out one release. This allows the team to concentrate on estimating one batch of (probably) related requirements at a time. The individual IRP sessions are short meaning that the overall time spent on release planning should be roughly the same as for a single monolithic meeting.

However, there is a gain in that the estimates should be of higher quality provided certain prerequisites are met. The good thing about these prerequisites is that the responsibility for fulfilling them falls, for the most part, with the Scrum Master and Product Owner and not with the team members. This leaves the team free to get on with the business of producing working software.

Crucially many IRP sessions can be held over a short space of time. In my experience planning 4-6 weeks of work can be planned comfortably every 2 weeks or so. Before long these sessions cumulatively provide a complete release plan made up by informed, considered estimates. Estimates the team believe in.

Prerequisities

Listed below are the prerequisites I find are required for IRP to operate effectively:

1 – Quality Requirements. The requirements must be fleshed out. It is impossible to provide accurate estimates to one-line stories whatever technique you use for planning. The Scrum Master should work with the Product Owner and/or Business Analysts to get each Story’s requirements into a suitable state for planning.

2 – Stories Grouped into Releases. The project’s stories should already have been grouped roughly into releases and an implementation order for the releases should have been decided. It is the Product Owner’s responsibility to do this (with the Scrum Master’s support) as the exercise represents a form of prioritisation. Depending on the outcome of any particular IRP session stories can, of course, be moved between releases.

3 – The Team’s Velocity. It is difficult to have an up-front release planning session without an idea of the team’s velocity. The same is true of any individual IRP session. Before the first IRP session the team should ideally have carried out several iterations of work and the Scrum Master should have an idea of their velocity. As the IRP sessions proceed so will the sprints. This will lead to a more accurate idea of the team’s velocity over time.

4 – Team Review Time. The team should spent some up-front time reviewing the stories before each IRP session. The Scrum Master can organise this by sending out the list of stories to be planned prior to each IRP session (perhaps a week beforehand). This step is crucial if the session is to proceed quickly. As a process gate I ask immediately prior to an IRP session if everyone has reviewed the requirements. If any person has not then I terminate the session and request that they do so before we reconvene a short time later. Unsurprisingly I have only had to do this once at our first session.

5 – Availability of Product Owner. The team will inevitably have questions around the requirements. The Product Owner and/or Business Analyst must be available to answer these questions quickly for the session to proceed smoothly. The Product Owner must also be available to make decisions around prioritisation changes.

6 – Availability of the Scrum Master. The Scrum Master runs the IRP session moving the team through the steps, keeps the session flowing and, where necessary, stops the team and Product Owner from getting bogged down in the details.

The Steps

With all the prerequisites fulfilled the IRP session can start. For materials you will require a whiteboard and cards filled out to represent each story.

I have illustrated this post with pictures taken at during one of our typical IRP sessions which proposed 12 stories for a release.

Step 1

The first step if to divide the board horizontally into three sections: Small, Medium and Large. The core mechanic of IRP is in the relative sizing of stories. Note that at this stage of the session that there is no mention of story points or velocity. These concepts feature towards the end of the session.

Click to Enlarge

Step 2

Next request that the team place each of the cards into one of the Small, Medium or Large columns depending on their perceived relative size to each other. What the Scrum Master wants to encourage here, and throughout the session, is for the team to collaboratively decide where each card should be placed.

Click to Enlarge

I tell the team to get stuck in at this point and make it clear that all team members have free access to the board. This tends to get the cards placed quickly and also provokes discussion between individual team members and between the team and the Product Owner. Do not move to the next step until some level of consensus is reached on the placement of the cards. However, make it clear that the placement is not final should any intractable disagreements take place.

Click to Enlarge

Step 3

Next the board is divided again, this time vertically, into three more Small, Medium and Large sections. The idea is to further divide the initial three levels of granularity by another level providing nine slots in which to distinguish the relative size of the stories. The team should now redistribute the stories – this time over all nine slots.

Click to Enlarge

This will no doubt result in yet more discussion and closer questioning of the requirements as the team attempts to distinguish between the stories in terms of effort, complexity and uncertainty. The Scrum Master should facilitate these discussions until, again, consensus on the placement of the cards is reached. Note that at this point it is perfectly valid for stories to move from any one slot to any other should the team change their mind on relative sizing as they compare stories and tease out requirements from the Product Owner.

Click to Enlarge

With the refined placement of stories agreed, ask the team to verify it quickly comparing the stories in each size section with those that are immediately smaller and bigger. Cards may be moved again as they deem appropriate. Note that in this example we did not require all nine sections (here we used only eight) to get a granularity of relative story sizes that the team was comfortable with.

Step 4

It is at this stage that story points are introduced to the process. Each section on the board now contains a set of similarly sized stories with the smallest stories in the top-left section and the largest in the bottom-right section. The idea is to assign a story point value to each story section and therefore to each story.

Click to Enlarge

We currently use the following story point values: 1/2, 1, 2, 3, 5 and 8. However, the technique is adaptable to any range. I start by asking if the stories in the smallest, top-left section are a 1/2 story point. If so I write 1/2 in that section and move on. If not I ask if they are 1 story point and so on. In this example the team chose 1/2. I then move to the stories in the largest bottom-right section and ask if they are 8 points. If they are I write 8 there, if not I ask if they are 5 point stories. In this example the team chose 5. I then turn to the second smallest section and ask if these stories are 1/2 pointers or 1 pointers (roughly the same size or roughly twice the size of the smallest stories). I then turn to the second largest section and so on.

This process continues, working towards the middle, until all of the story sections are assigned points. I then ask the team to cast their eye over the proposed story point estimates to verify whether or not they are happy with them. If they are then the Product Owner and team can be dismissed for a while. If they are not we can move individual cards until the team is satisfied.

Step 5

The Scrum Master can now total all of the individual story point estimates to get a figure for the entire release. For this example we have:

1 story x 1/2 SP= 1/2 SP

3 stories x 1 SP = 3 SP

1 story x 2 SP = 2 SP

4 stories x 3 SP = 12 SP

3 stories x 5 SP = 15 SP

Total: 32.5 SP

Combined with the team’s sprint velocity of, in this case, 14 story points, we get the following calculation for the sprint duration required to complete the release’s work:

32.5SP / 14 = 2.32 sprints

Our sprints are two weeks long which gives us a release work duration of 4.64 weeks. I tend to round up to the nearest week which gives us an estimate of five weeks for this release.

Step 6

Armed with an estimate the final step is to validate it with the team. The team’s buy-in to the estimate is crucial. To get this buy-in the Scrum Master reconvenes the team (but not the Product Owner) and informs them of the estimate in weeks. As transparency is important the Scrum Master should also detail the process by which the figure was calculated. The Scrum Master then asks the team if they think that the estimate is reasonable, i.e. do they think they can complete all of the release’s work in that time?

I do this using the fist of five. If anyone votes with a one or two then some discussion can take place as to why they are uncomfortable with the estimate. If the responses comprise threes, fours and fives then the IRP is over and the estimate can be provided to the Product Owner and be incorporated into the full release plan. Should the date prove to be disagreeable to the Product Owner then they can move some work between releases and see the impact that this has on the forecast date. With all the of the figures available this kind of what-if analysis is straight forward. Note that any such changes should be verified with the team to ensure no dependency issues are introduced by reordering stories.

Sprint Planning and Actuals

Note that the IRP estimates do not in any way negate the requirement for sprint planning. This still needs to happen at the beginning of each sprint and I do not make IRP estimates available at this time. All stories must be re-estimated as a lot may have changed between the IRP and the sprint when the work is to be done. However, the IRP assists with sprint planning as the team have seen all of the stories before and have discussed them together. I do, however, compare IRP time estimates with the actual time taken to complete releases as it is interesting to see how accurate IRP is against actuals. The reason I believe so firmly in this technique is that, so far, estimates have been fairly close to actuals (plus or minus 1 week for 4-6 week releases).

Summing Up

IRP is a technique that has worked well in our team. While we cannot provide one big release plan in a single hit we have been able to provide regular release plan updates from early on in the project which prove to be reasonably accurate. Repeated IRP sessions have quickly led to a complete release plan early in the project’s life. I have found these sessions can be run very quickly with 4-6 weeks worth of work being planned in just 30-40 minutes

The IRP technique does require some preparation from all parties. However, the preparation effort in terms of requirements definition and team review pays dividends later when the stories are actually implemented as nothing about the work is a surprise to the team.