Guidance – Branching for each Sprint



There are a lot of developers using version control these days, but a feature of version control called branching is very poorly understood and remains unused by most developers in favour of Labels. Most developers think that branching is hard and complicated. Its not!

What is hard and complicated is a bad branching strategy. Just like a bad software architecture a bad branch architecture, or one that is not adhered to can prove fatal to a project. We I was at Aggreko we had a fairly successful Feature branching strategy (although the developers hated it) that meant that we could have multiple feature teams working at the same time without impacting each other. Now, this had to be carefully orchestrated as it was a Business Intelligence team and many of the BI artefacts do not lend themselves to merging.

Today at SSW I am working on a Scrum team delivering a product that will be used by many hundreds of developers. SSW SQL Deploy takes much of the pain out of upgrading production databases when you are not using the Database projects in Visual Studio.

With Scrum each Scrum Team works for a fixed period of time on a single sprint. You can have one or more Scrum Teams involved in delivering a product, but all the work must be merged and tested, ready to be shown to the Product Owner at the the Sprint Review meeting at the end of the current Sprint.

So, what does this mean for a branching strategy?

We have been using a “Main” (sometimes called “Trunk”) line and doing a branch for each sprint. It’s like Feature Branching, but with only ONE feature in operation at any one time, so no conflicts Smile

Figure: DEV folder containing the Development branches.


I know that some folks advocate applying a Label at the start of each Sprint and then rolling back if you need to, but I have always preferred the security of a branch.


  • being able to create a release from Main that has Sprint3 code even while Sprint4 is being worked on.
  • being sure I can always create a stable build on request.
  • Being able to guarantee a version (labels are not auditable)
  • Be able to abandon the sprint without having to delete the code (rare I know, but would be a mess if it happened)
  • Being able to see the flow of change sets through to a safe release
  • It helps you find invalid dependencies when merging to Main as there may be some file that is in everyone’s Sprint branch, but never got checked in. (We had this at the merge of Sprint2)
  • If you are always operating in this way as a standard it makes it easier to then add more scrum teams in the future. Muscle memory of this way of working.

Don’t Like:

  • Additional DB space for the branches
  • Baseless merging between sprint branches when changes are directly ported
    Note: I do not think we will ever attempt this!
  • Maybe a bit tougher to see the history between sprint branches since the changes go up through Main and down to another sprint branch
    Note: What you would have to do is see which Sprint the changes were made in and then check the history he same file in that Sprint. A little bit of added complexity that you would have to do anyway with multiple teams.
  • Over time, you can end up with a lot of old unused sprint branches. Perhaps destroy with /keephistory can help in this case.
    Note: We ALWAYS delete the Sprint branch after it has been merged into Main. That is the theory anyway, and as you can see from the images Sprint2 has already been deleted.

Why take the chance of having a problem rolling back or wanting to keep some of the code, when you can just abandon a branch and start a new one?

It just seems easier and less painful to use a branch to me! What do you think?


Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Product Backlog Management Skills with Joanna on 14th December 2023
Virtual Traditional
14-15 Dec, 2023
09:00-13:00 CET
2 half-days
Immersive Professional Agile Leadership Essentials with Joanna on 12th January 2024
Virtual Immersive
12 Jan-1 Jan, 2024
13:00-17:00 GMT
8 weekly half-days
Immersive Professional Scrum Product Owner with Martin on 17th January 2024
Virtual Immersive
17 Jan-6 Jan, 2024
13:00-17:00 GMT
8 weekly half-days
Immersive Professional Scrum Master (PSM) with Dan on 17th January 2024
Virtual Immersive
17 Jan-28 Jan, 2024
13:00-17:00 GMT
7 weekly half-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood Scrum Masters: Unlocking the Power of Liberating Structures 🚀  In the dynamic world of Agile and Scrum, Scrum Masters are continuously seeking innovative ways to enhance collaboration and effectiveness within their teams.  Introduction: Embracing Liberating Structures in Scrum  One transformative approach that’s gaining traction is the use of liberating …
Martin Hinshelwood
Business Leaders face a key challenge when scaling their organisations effectively while maintaining the distinctiveness that made us successful in the first place. Many frameworks and methodologies, such as Scaled Agile Framework (SAFe) or the Spotify Model, promise a structured approach to scaling, but do they genuinely fit our unique …
Martin Hinshelwood
As we inch further into the dynamic landscape of the 21st century, our long-established Alpha organisations stand on shaky ground. The organisations whose DNA is infused with strict command and control, woven into the fabric of every process, are feeling the tremors of a rapidly evolving, technologically charged market. Not …
Martin Hinshelwood
Under the ruthless canopy of the red market, I find myself staring at the bloated behemoth of an Alpha organisation, huffing and puffing in a vain attempt to keep up with the frenzied pace of the modern world. The Alpha model, once a paragon of order and efficiency in the …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.