Reducing Schedule Risks: Feature Branches
Software development projects are subject to a number of risks. One of these risks is schedule risk. By this I mean that you may not be able to ship on time because of some nasty discovery while executing the project.
Of course you don’t know what you don’t know. You cannot foresee what you will discover as you work through the project plan (or backlog). No matter how much effort you put in planning your project, breaking down the stories, even running some spikes, you will find that you cannot totally eliminate surprises that add to your workload.
Although we cannot totally eliminate that risk there are techniques that help with mitigating it. Firstly you can build in an allowance for discovery into your plans. Some people would call it a buffer.
A different option is to break your deliverable into multiple features. Often you will observe that most of the features are completed within the deadline while a small number may overrun. You will run into a problem, though, if you are using a single branch in the version control system (VCS) for your work. Your only option will be to deliver late once all features are complete.
Therefore a different approach is using feature branches. For each feature that you have scheduled you create a separate branch. Once the feature is complete you merge it back into your main branch, e.g. ‘trunk’ in Subversion. As you approach the deadline, e.g. the release date, you now have options. You can either ship with just the features that are complete or you wait until some or all of the remaining features are complete as well.
Of course this changes the scope of the release. However, if the features are worked on in their priority you may be able to ship the more important features even early or at least on time. This is sometimes a viable alternative to not shipping at all.
In the teams that I have worked with this approach is working quite well. There are a few more aspects to this but I’ll cover these in a future post.