Branching for Scrum
This article presents a perspective on Source Control Management (SCM) using Team Foundation Server (TFS) with Scrum projects. Although I start with a short overview of Scrum to lay the foundation for the concepts, the essence of this article is to present TFS Branching Concepts for Scrum projects, large and small. This article is an extension of the current Microsoft VS ALM Rangers Branching Guidance 2010, which you can download from here: https://tfsbranchingguideiii.codeplex.com/
If you are familiar with Scrum you have probably seen an overview diagram of the Scrum process similar to the following illustration:
This illustration gives a very high-level overview of Scrum. Scrum projects use a more agile process as contrasted with the waterfall approach. Scrum does not start with a lengthy and time-consuming effort to define all of the product’s requirements before proceeding with development. Rather, the Product Owner prepares a Product Backlog which is a prioritized lists of all functionality desired in the product.
A Scrum project is organized into Sprints that are typically 2-4 weeks in length, although for some projects Sprints may be shorter or longer, as long as six weeks in some cases. The goal of a Sprint is to take a subset of the functionality from the Product Backlog and deliver a potentially shippable working increment of software.
In this next illustration, more of the roles and process are elaborated:
The Product Owner is responsible for creating the Product Backlog during initial planning session for product development. What typically follows is a one-day Sprint planning session where all members of the Scrum Team participate. During the Sprint planning session, the Scrum teams determines how many of the prioritized items from the Product Backlog they can successfully build into a working increment of software by the end of the Sprint.
A typical Scrum team is 5-9 people with one person serving in the role of Scrum Master. Smaller Scrum projects may only have a single Scrum Team. Larger Scrum projects scale by having multiple Scrum Teams rather than having one very large Scrum Team. I will cover the branching implications of larger Scrum projects later in this article.
As shown in the preceding diagram, each Sprint lasts from 2 to 4 weeks. During this time, the Scrum Team takes items from the Sprint Backlog and builds a working increment of software. The Scrum Team holds a daily Scrum, lasting approximately fifteen minutes and facilitated by the Scrum Master. Each member of the team answers three questions in the Daily Scrum meeting:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
If you take the Sprint activities from the preceding diagram, you can create a flattened picture to show these activities on a timeline:
As you can see from the preceding illustration, the Initial Planning session(s), where the Product Owner creates the Product Backlog takes place prior to the first Sprint. On the day one of the first week of each Sprint, a Sprint Planning session creates the Sprint Backlog. Every day during the Sprint the Sprint Team holds the daily Scrum.
For the remainder of the days and weeks of the Sprint, the Sprint Team works on various activities while building the working increment of software for all of the items on the Sprint Backlog. At the end of each Sprint, a Sprint Review meeting provides the product stakeholders (typically the Product Owner, Scrum Team, Scrum Master, management, customers, and others with a short demo of the working software increment they deployed at the end of the Sprint.
The Sprint Review is followed by a Sprint Retrospective where the Sprint Team assess the success of the Sprint against the original goals of the Sprint.
The product is complete when, over several Sprints, all of the items of the Product Backlog have been turned into a working software solution. There may be periodic releases after every few Sprints along the way.
The following illustration shows the iterative, incremental process of a Scrum project. Each Sprint in this example has a four-week timebox. During the Sprint a working increment of software is built, tested, and deployed. At the end of each Sprint, work begins on a new Sprint with a new Sprint backlog to create the next working increment of software.
The following illustration shows a Scrum project comprised of six-week Sprints. Each of the software increments is labeled in this example with a version number (for example v0.1, v0.2, v0.3, and so on):
The following illustration shows a proposed branching model for a single Scrum Team. This branching is based on the basic branching plan from the VS ALM Rangers Branching Guidance 2010 (https://tfsbranchingguideiii.codeplex.com/).
There are some key differences between the branching model in the preceding illustration and the basic branch plan. You will note that in each of the three branches (MAIN, Development, and Release), the color of the branch changes over time. I am using color to indicate the software version currently contained in each branch.
You will note that during the first Sprint, both the MAIN branch and the Development branch are used for developing and stabilizing the vNext release (v0.l) shown in blue. At the end of this first Sprint, vNext is deployed. vCurrent is now v0.1. During the second Sprint, MAIN and Development are used for developing and stabilizing vNext which is now v0.2 shown in red. At the end of the second Sprint v0.2 is released and work begins on v0.3. The process continues until all of the Product Backlog items have been delivered as working software. Development of the product is now complete and the full product is released.
As stated earlier, for more complex products or product lines, there may be larger Scrum projects comprised of many more Scrum Teams. An example is shown below:
In the preceding example, the Product is more complex. The Product Backlog is therefore much more extensive. One can either extend the product development for a longer timeframe (more Sprints), or one can have multiple Scrum Teams working in parallel over a shorter timeframe. The preceding illustration shows three Scrum Teams working in parallel. Each of these teams contributes to the working increment of software delivered at the end of each Sprint. At the end of each Sprint, the Scrum Teams all participate in a joint Sprint Review. Each team then has its own Sprint Retrospective followed by a Joint Retrospective prior to starting the next Sprint.
To support larger Scrum projects with multiple Scrum Teams working in parallel development side of the basic branching model becomes more complex. As shown below, each Scrum Team has its own development branch. In a future blog, I will address more of the branching process including how and where code from each of these isolated development branches can be integrated and then released.
For even more complex products, more Scrum Teams can be added, as shown below:
Scrum projects can scale to very large efforts, simply by adding more Scrum Teams to the project:
The branching implications for very large Scrum projects are similar to the branching implications for very large iterative development efforts, or even very large efforts employing a waterfall approach. The complexity in the branching model is primarily concentrated on the development side of the model Adding more Scrum Teams requires adding more development branches (assuming each team requires isolation in their own branch during development). Adding a large number of development branches increases the need for merging, merge conflict resolution, and other management activities. Consider balancing the need for each Scrum Team to have it’s own development branch against the cost of having large numbers of development branches. Consolidate Scrum Teams into the same development branch whenever possible.
In the next blog, I will go into greater detail on the branching and merging process and the implications of having multiple development branches on this process.
Download the VS ALM Rangers Branching Guidance here (https://tfsbranchingguideiii.codeplex.com/). In the next release of the branching guidance, we will consider adding new scenarios to address Branching for Scrum and related challenges.