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.