Scrum and the branching strategy
When using Scrum, it’s critical to have a product that can be released at the end of each Sprint. To be able to release so frequently you need to have a good branching strategy. Fortunately, there are tools that allow you to manage the software in the best possible way both in terms of tools and processes.
Git and Gitflow
The most widely used versioning system for managing source code is Git. Git gives you the ability to create branches in a very simple, fast way, and without requiring too much hardware resources. In the past, many companies used SVN as their preferred versioning system; one of Git’s biggest advantages over SVN is the ease of creating both local and remote branches.
GitFlow is a set of guidelines, which suggest the best way to manage branches with Git; by following the guidelines you can always have stable software versions that include a set of known features.
Atlassian GitFlow
The figure above illustrates the branching strategy recommended by GitFlow. In the master branch (blue) there is the last official release of the product; in the Develop branch (purple) there is the latest full version of the features developed; the feature branches (green) include the features under development that still need to be merged into the Develop branch. This type of branch management solves many problems in managing the versioning of your code. It also helps to have in the Develop branch the latest stable version of the product including all features implemented and that can be released at any time.
Scrum and branching strategy
Having a well-defined branching strategy that helps to have a product that can be released any time is the key to being able to release, if necessary, a product increment after each Sprint. Although some features that need to be implemented within the Sprint are delayed, they do not affect the operation of the product because they remain on feature branches without being merged into the Develop branch. A good practice is to run automatic regression tests before merging the software to the Develop branch; so you can be sure that all previously implemented features are not impacted by new developments.
Final considerations
Projects that do not have a clear, shared branching strategy, create code conflict issues, code changes, and regressions due to the two issues mentioned above. The product is ready to be released, at best, when you need to make an official release every 4-6 months.
Worrying about the quality and maturity of the code to be released only when you are near to the official release date results in issues that may not be solvable in the short amount of time that you identify to stabilize your code. This type of approach leads to situations of high stress where it becomes necessary to work outside of office hours to try to recover problems that are most often not solvable quickly. Adding new features in short-duration product increments solves these kinds of problems and help to be focused on the real needs of end users.
If you liked the Scrum article and branching strategy and you are interested in Scrum you can read more articles in the Agile section