Agile stabilization and release management

You should not have stabilization sprints. Your software should be releasable every sprint. This means that if you need stabilization, that has to happen within each sprint and not just before a release. Once you achieve this, release planning becomes a product owner concern ("What features to I need in order to release?") and stabilisation a team concern (definition of done).

The same applies to bugs and technical debt: it's stuff that is always fixed, as needed and does not require stories -- in fact, it's normally part of each story: it can't be "done" unless it's stable and properly refactored.

I realize that this does not answer your question directly, but stabilization is not an agile concept at all, so it makes no sense to ask how to do it with Scrum.

Edited to address comment:

According to Scrum, bugs found pre-release are to be handled within the iteration. A story is not normally considered "done" if it has bugs. If you can't ship it, it does not have value. Also, according to basic Agile principles, teams should work at a sustainable pace. If you need to basically stop development in order to address debt or bugs, then you are not working at a sustainable pace. Decrease your velocity, ship less features, but without bugs.

Usually stabilization happens in teams that have a separate QA team checking features post hoc. This does not fit in the Agile or Scrum model. Teams should be cross-functional and able to ship a feature independently.

Overall the thing is, many companies say they do Scrum or Agile without understanding the deep changes it entails in the way software is built. If you are not prepared to build software according to these methodologies, don't use it as a "management add on" on different practices.

Whether you give them the name 'stabilization' or just 'Sprint 12' doesn't matter, at some point your team will have stopped initial development of stories and will be doing sprints of technical debt or closing off stories that haven't been done because issues were found and you couldn't close them. These are just normal agile sprints, my guess is your team is like ours and knows we'll need that calendar time to deal with the "I didn't think of that" stuff.

In our shop, if we initially forecast a release backlog of 400 points, and initially think we can do 100 points velocity based on history, that should theoretically mean we can do that in 4 sprints. However, we also have enough experience on projects to know that our estimates of velocity and total backlog are not always correct. New functionality might be required for the MVP, an unforeseen delay might block us from completing something, so we plan a similar 'sprint' for dealing with that. So we might put 5 or 6 sprints into our calendar plan to account for the level of unknown.

Now, the amount of time you are forecasting for 'stabilization' indicates an organizational issue with delivery if you need almost as much time to stabilize as to initially build. As others have mentioned, you likely need to embed your testing earlier on in the phase so that you are getting your feedback earlier. By using Continuous Testing techniques you will have your team cleaning up the stories as you go. That way, when your team is actually 'done', the release is ready.

ASSUMING YOU MAKE THIS ADJUSTMENT: Now we get to the release management part of our question: how do you deal with trying to finish off the release while also starting a new release in parallel? Typically, the last sprint or two might not have enough work in it for your initial release to keep the whole team busy. This is when you can start bringing in your next release stories to keep the team at capacity. From a code management perspective, using your favourite branching strategy will help to keep the codebases isolated and your team can switch between branches based on the task they are working on. From a task management perspective, you need to be able to clearly delineate to the team which release a feature is for so they know where to put it.

Should you split the team? Personally, I have found this helpful to keep team members focused, but it really only works if your team can truly work on almost anything. If you have specialists at all, they will have abilities that everybody needs and they will need the flexibility to jump between releases. If you can define a core group to deal with both releases and then other team members which can float this can allow for a more balanced attack.

WHAT IF YOU ARE NOT CONTINUOUS TESTING? If you are building a bunch of code, throwing it over to another team, and then moving on to the new release and waiting for feedback, you'll need to manage your team differently. This is a more 'waterfall' manner of delivery and means the initial release team can't predict when feedback will come, or how much there will be. This makes sprint planning harder for the next release since you can't be sure how much work from the initial release will be there. In this scenario, you may need to plan your new release sprints to have a 'buffer' in the capacity to account for feedback from the test team. You'll likely use your whole team for the new release at first, and once you have some technical debt to resolve you can start forming a group to deal with that and clear it out.

I apologize because this may sound a bit militant and harsh, but if you want to play the top level agile game, you better be prepared to bring in the big guns, work like a madman, and never compromise.

I would considering shorting your sprints and making quality and testing a top priority. I've worked with agile teams releasing weekly and bi-weekly and find anything long than that can be problematic. A good solid test suite (100% coverage along with automated browser tests) and mandatory reviews of all code will do a lot to reduce bugs. The advantage of the weekly release cycle is that bugs are fixed almost immediately and stability sprints become a non issue. This sort of development requires a massive amount of discipline and must be driven militantly from the owner. If your company isn't willing to put forth that level of commitment you're just going to be another mediocre agile wannabe so don't waste your time.

To comment on your questions:

1. You only need one team. People fix there own bugs since they have the most knowledge of them and with a weekly release schedule things should be fresh.

2. Sizing and debates are pointless. Developers have tasks and they are responsible for estimations and scheduling. Management can overrule this obviously, but bugs should always be addressed first unless there is a critical business reasons not to. Treat technical debt like bugs. There shouldn't be any unless again a critical business reason creates it. Ideally technical debt should not make it past code review. If it does, like a bug fix it in the next release.

3. Bug and new features are the same. There is no reason to differentiate as it's their priority that matters.

Finally, automate, automate, automate, and then find a way to automate some more. There is no way to accomplish this level of effort without automation.

Stabilization fit's into agile just fine. It's simply not a feature.

This is technical debt. Where this fits into agile is the amount of features you accept responsibility to deliver. Agile says you don't promise the product owner that this sprint will "stabilize" anything. That doesn't mean anything to them. You say, "We anticipate our velocity is going to drop because we've realized a need to clean up. We'll commit to only these 3 things." Make darn sure those 3 things are small enough that it will leave you time to clean up.

Sure, you should be stable and clean every sprint. But sometimes the code needs a big refactoring. Agile doesn't say you can't do that. It says you get no credit for it.

Just because you get paid to cut down tree's doesn't mean you shouldn't sharpen your axe. Just don't expect to get paid to sharpen your axe. Your axe is your responsibility.