Posted on April 14, 2017
by Doug Klugh

High performing Agile teams are always expected to deliver multiple features within an iteration.  To do this effectively, you must have a configuration management process and branching strategy that support concurrent feature development.  Being able to develop features in isolation will enhance your team’s ability to deliver value to your customers quickly while helping to improve quality control.

This is especially useful when delivering within a Kanban process.  Feature branching will enable the team to deploy the features it chooses to release at any time.  If one or more features are not quite ready for prime-time when you want to deliver a release to your customers, it will be as easy as deploying the latest build from your Continuous Integration (CI) branch; which of course, has already been fully integrated and tested.  No more waiting until all of the features earmarked for a release are fully baked.  You may not be delivering everything the customer wanted, but if you deliver the high-value features quickly and often, they will be happy more times than not.

The Value of Feature Branching

To realize the value of Agile, you must be able to deliver value frequently, with a high degree of confidence in the quality of your product.  Feature branching facilitates agility, supports quality assurance and quality control, and provides flexibility that is needed to keep your customers happy.  This is achieved by enabling each developer to work on a feature that is isolated from changes occurring elsewhere.  Team members can work on features concurrently, at their own pace, without impacting the development or delivery of other features.  And this works especially well in a CI environment.  The CI branch acts as a communication point.  Even if team members do not coordinate feature development, any conflicts between features will be discovered within a day of them forming; making it easy to resolve conflicts and mitigate associated risks. 

Feature Branching Explained

Feature branching is achieved by creating a branch off of your main development branch, or CI branch if you're doing continuous integration.  In a Distributed Version Control System such as Git, you’ll do this in your personal repository; but this is also easily achieved in a centralized Version Control System such as Perforce (P4), Subversion (SVN), or Team Foundation Server (TFS).

A feature branch is used to isolate development for one specific feature (or user story).  If your team is effective at keeping features (user stories) small, this branch will be short lived.  Once the feature is completed and merged back into the development (CI) branch, that feature branch should be deleted.

Functional testing should be completed within the feature branch, then automated integration and regression testing should be performed (automatically) upon merging the code back into the CI branch.  Quality gates should also be used to ensure the health of your builds (see Building Success with CI).

Figure 1 below depicts a Trunk used for all production builds.  While some people refer to this as the Master branch, I prefer to use the analogy of a tree, where production code resides on the trunk and all other branches split off of the trunk.  Also depicted below is a Dev branch used as the CI branch.  This example shows three features in development at different times, with Feature 2 being developed concurrently with Feature 1.  Once each feature is merged back into the Dev branch, those branches are no longer needed and should be removed from the source control repository.
Figure 1 - Feature branches
Figure 2 shows an effective method for managing production patches by simply creating a Patch branch off of the Trunk, applying a defect fix there, then merging back onto the Trunk.  A merge down to the Dev branch should also be performed at the same time to ensure those changes are propagated for all feature development.  Individual features may also pull those changes into their respective branches (as depicted with Feature 1) to make sure they have the latest changes and make merging back into the Dev branch a little easier.  But even if they don't pull in the changes (as depicted with Feature 3), those changes will be included when they merge back into the Dev branch.
Figure 2 - Feature branches + patching
When you decide to deploy a new release, simply create a Release Candidate (RC) branch off of the Dev branch, perform all final release activities (such as updating release notes), then merge onto the Trunk and back down to the Dev branch.  Each merge should automatically perform final integration and regression testing.  Once that is done, you can easily deploy from the Trunk.
Figure 3 - Release candidate
Figure 4 makes note that every merge onto the Dev branch or the Trunk should automatically create a build and kick off a suite of automated integration and regression tests.  Quality gates should also be used to roll back all changes if any of the builds or tests fail for any reason.  This is a very effective way to maintain confidence in your code and quality in your product.
Figure 4 - Annotations for automated testing


Bringing individuals together as a software development team requires a great deal of planning and coordination.  This is often hampered by having to lead team members with various skill levels, working at different speeds.  While there are times when it benefits the team to pair up team members, there are also times when you need to decouple them.  Pair programming is a great way to address quality issues, but enabling team members to work independently on separate features (without stepping on each other’s toes) is a very effective way to increase team velocity.  Utilizing a feature branching strategy helps to decouple features and provide a great deal of flexibility in delivering value to your customers.  Combined with continuous integration, this strategy will all but ensure high quality and fast time to market.
Agile application development automated tests branching strategy CI code defects DevOps DVCS feature branching Git Perforce quality risk SCM SVN TFS User Story VCS

Doug Klugh

Doug is an experienced software development leader, engineer, and craftsman having delivered consumer and enterprise firmware/software solutions servicing more than one billion users through 20+ years of leadership.

1 Comment


Susan Ricci · Apr 21 2017

This is especially applicable in fast paced environments where changing market conditions impacts feature priorities.  This can also assist with the defect identification.

Similar Articles

subject Article

Agile Is More Than Process

There is more to Agile than estimating stories, collaborating with customers, and showing working software.  Agile is also about technical excellence.  And this is where many Agile teams drop the ball.  All too often, teams focus too much on process and not enough on technical practices.  If the effort, complexity, and risk is too great for your team to extend and maintain their software, they will struggle to deliver functionality to their customers at the end of each iteration.  They will struggle to deliver working software as promised.

Read More
subject Article

Planning for Failure

Quality software is built around the expectation of failure.  To deliver reliable software, you must always plan on things breaking.  In designing and building software for critical systems, such as air traffic control or nuclear power plants, runtime reliability is absolutely critical.  And while human life may not hang in the balance of a business application, the life of the business may.

Read More
subject Article

Why Bother With TDD?

Does it really make sense to test code that hasn’t even been written yet?  Or to disrupt your development mojo every minute to stop, write tests, and refactor code?  It does if you want to deliver software faster, through better code, with fewer defects, and greater agility.  As software development leaders, it is important to understand that Test Driven Development goes well beyond quality control.

Read More