Managing sprints for multiple releases of the same product for the same team

Question

How do you plan a sprint for the same product with two releases when the same team will be working on both releases during the sprint cycle?

To give some background, our product gets released out to customers every 6 months and we provide weekly automated releases with bug fixes and small features to those customers. Let's call that release Live. When we do a live release, we branch it off and increment the version number of the trunk, which we'll call Core. So if Core was 1.20, then branching Live off will make Core 1.21.

We try to avoid major changes to the Live release once it's signed off because we deal with critical data that can potentially cause serious harm to people if we get things wrong. We have QA and testing teams in place on each release and an automated builds and auto UI tests through TeamCity.

When it comes to planning, how should you plan a sprint across multiple versions and determine where that work should be done, e.g. which release? So if I have 20 hours of defects in the Live release I want to plan in, I want that to be part of my sprint alongside all the other Core feature work because they're both the same product. Anything done in Live will be merged back in Core.

Currently for planning I'm having to calculate and reduce the availabilities of the team members in alignment with how much work there is an plan the two sprints separately, which is a lot of work.

We use Axosoft for our planning, which has a product with many releases and each release can have many sprints. So if we use it as intended then we end up with a separate sprint for both Live and Core. We can give both sprints the same name and number, but as it's the same team working on both, management of the process is very difficult as velocities and availability are not shared between the two sprints. This leads me to believe that there should really only be one sprint.

I do wonder if we're just limited by Axosoft and what we should be doing is just putting a flag against each backlog item to say where it should be fixed/completed, however looking at similar products they seem to have the same issues.

Answer 1

Sprints are different than releases. Although the outcome of a Sprint is a "potentially releasable Increment", the team can produce a "potentially releasable Increment" at any point in the Sprint and the Product Owner can release it at any point.

In the context of the Sprint, the important thing to consider is if the work can get to Done before the end of the timebox. When you reach the end of the Sprint, the work planned should be Done - this would indicate that the team is capable of forecasting the work they are able to achieve. If there are mid-Sprint releases, then this would need to be considered as a subset of the work will need to be completed and Done before the end of the Sprint.

In your case, each work item (ticket, issue, etc.) should be labeled with where the work needs to end up. Otherwise, branching and branch management and such is outside of the scope of Scrum. The team, when planning, should be aware of work that is due before the end of the Sprint and consider this when organizing the work for the Sprint.

Answer 2

In Scrum, there is no correlation between Sprints and Releases. A release can contain the work done in multiple sprints, but at the same time can multiple releases be done during one sprint.

It should be possible to indicate for each ticket (user story, bug, etc.) in which release it is expected to be delivered and separately to indicate in which sprint it is planned that the team will work on it. If your tool does not allow that, then that is a limitation of the tool, but it is not given by the Scrum process.