I'm working on an Agile program and we are debating on how to deal with what we call "stabilization sprints". We have to build our team and decide on several key items but it seems there aren't really a well defined guideline to help us decide about them (or we can't find them) so I was hoping to pick your brain on this.
Our first release is due in June, we have three months of stabilization but in parallel we need to build a team and start working on next release due for October and then a 3rd release for next June.
Here are the items we want to decide on:
Do we build two separate teams to deal with next release and stabilization tasks? On one hand having a single team (several pods) to deal with both helps us to load balance our resources better and assign developers with deeper knowledge of the issues require fixing to them. On the other hand not having a dedicated team for next release makes it deficult to plan our next release.
Do we size issues identified (bugs to be fixed during stabilization, technical debts) or we deal with them by assigning a percentage of the pod's velocity to bug fixing as we used to do for our normal development sprints? Sizing them helps to plan better but creates a need for debates and meetings we want to avoid.
Do we combine our stabilization tasks with next release story cards or keep them separate? This is kind of continuation of the first question. If we decide to have a single team to deal with both stabilization and new release then do we really need two backlogs or just a single one?
I've been looking for a good book/article that describes the best practices to deal with an Agile project with multiple releases planned specifically to explain the team structure and estimation model but can't find anything good.