Release Planning

It's important to understand that there are some different levels of planning on agile teams. And so I want to share with you one level called release planning. So this idea of release planning, it's a sort of level above team planning. You know, teams are sprinting and they're doing their work on their sprint timebox and they're committing to that sprint backlog. But this is a higher level view. Often the release plan is started in a sprint zero, a sprint zero activity. But there's some components of release planning and I want to describe some of those to you now. You know, agile planning is really all about progressively elaborating the plan. Kind of a fancy term for just saying we're going to discover things as we go, we're going to learn as we go. So a release plan is not like set in stone or something. You know, many traditional projects plan the work and work the plan and you know, even if the plan is taking you in the wrong direction, follow the plan. Well, we're suggesting that release planning is more about elaborating to get to the best possible product. We're aligning this plan, this release plan to the product vision. Within release planning, we're talking about things at the epic level. We're beginning to align those to our strategy and our vision. Product management, product owners, business owners, sort of a broader audience than the than the scrum teams are in release planning and it should be occurring on a regular cadence. Again, we're elaborating and learning as we're going and we're updating what's called the release plan. Very common term in the industry. Used to know when we can lock in our releases and lock in our dates. We want to sort of make that a living document, if you will. There's nothing wrong with committing to release dates. In fact, you'll probably be required to do that. I'm a fan of dates. I'm a big fan. Lock them in. I love that. What we want to do is make sure that our scope can flex our scope. You know, the things that we're going to deliver on. That date has some flexibility. So lock in your dates, lock in your release dates. One other piece that the release plan will have is our high level dependencies. Maybe teams are dependent on other teams, internal or even external. What if teams are dependent on an external supplier or an external resource? We'd want to have that captured in our release plan as well. Some guidelines to consider for better release planning include a well maintained product backlog that contains enough items to cover up through the next release, our product management product owner should be available to help identify dependencies and risks and discuss priority. Team members should be available to clarify with product owners and stakeholders any of the items in the release plan. We identify high level dependencies and risks and we make our commitments to the results only for the next sprint and commit to adapting the product backlog based on what we learn. And of course our Scrum Master is there to facilitate the event and ensure that there's quality in the product backlog. Items we're committing to and just a few final notes to keep in mind about a release planning session. The teams need to understand their velocity. Velocity is a description of the amount of work that we can deliver every sprint as a team. It's a predictability measure more than anything else. We finished roughly this many user stories and story points in the last sprint. We use that to estimate going forward to the next sprint. We cover much more on velocity in another section. So again, the release plan, another level of planning within Agile. See, I told you there is more planning in agile than traditional. We just don't do it all at once. We do it like all the time. And as a part of our release planning session, one of our, one of our outputs will be the release plan itself. This is sometimes can be referred to as a roadmap. But the key I want us to remember here before we describe it is, is that it doesn't necessarily represent commitment, the next sprint that we're committing to for sure, but it might have, you know, like 4, 5, 10 sprints on it. And so it becomes a roadmap, if you will, something that we can forecast against. It's really handy for our executive sponsors and stakeholders. Very important for them to have. It allows for a place for us to put milestone events, maybe an investor demo or a release, whatever those things are out in front of us can be displayed on this plan. So let's take a look at one. We list our sprints across the top. You probably put the dates in there, each sprint in a column and then you can begin to load up the stories that are going to be completed in those sprints or that we think anticipate will be completed in those sprints and we get more refinement, more fidelity on the closer in sprints than the farther ones out. So a little bit farther down the road those are sort of vision. This is where we think we might be, is where we hope to be in the release plan itself. A couple things that you keep in mind with a release plan, again we'll have our team's velocity, that idea of how much we think we can complete in each sprint. We'll load up those sprints with stories. So you usually have some rough order of magnitude estimation on these stories done by this point, but a release plan allows us to see sort of when those epics might be being delivered against and provides that forecasting tool that is so important on our teams.