Release Planning in Agile Projects
Release Planning in Agile Projects
Worried about how to track high level progress on your agile projects? Not sure if you are going to hit your due date? Effective Release Planning can help!
Join the DZone community and get the full member experience.Join For Free
"In preparing for battle I have always found that plans are useless, but planning is indispensable" - Dwight D. Eisenhower
There is always a fear when embracing Agile that things will fall into chaos and that planning and strategy go out the window. I have been on projects that have run into these types of issues, and a big part of that stemmed from the team losing sight of the big picture goals and direction for the project. One thing that has been very helpful in preventing chaos and keeping things on track has been: release planning.
What Is Release Planning?
Release planning may mean different things in different organizations, but for this article, I will define it as the process of developing a high-level plan that helps track overall progress within a project and provides a roadmap for upcoming features and key dates that the team will need to be aware of. Release planning is NOT something that is done once to create a plan that is set in stone. It is something that should occur regularly so that plans can be inspected and adjusted regularly to reflect information that has been gained as work is getting completed.
Why Is It Important?
- Big Picture View: While teams are focused on accomplishing the sprint goals, it can be easy to lose sight of the larger strategic goals for the project. By having a release plan that will show things that will be coming up, the team can at least have some situational awareness as they are building their current features. Are they going too deep into a particular problem? Is something that is in the current sprint going to become irrelevant two sprints down the line? Knowing the big picture can help the team better self organize within their individual sprints to better position themselves to hit the larger goals.
- Prioritization / Sprint Goals: One of the most important tools that organizations gain when they begin to embrace Agile is prioritization. It may seem obvious, but it is all too common for teams to run into things that seem like they are "equally high" priority. When there is a release plan in place, teams can refer to this to help them better determine what their real priority is and set their sprint goals accordingly.
- Longer-Term Forecasting: For many businesses (particularly larger enterprises) that are adopting Agile one of the biggest concerns is the perceived inability for teams to deliver on longer-term projections consistently. Many times teams will be asked when something will be done, and all they can answer with is a shrug. Although a release plan doesn't guarantee when different features will be ready it can provide enough information and confidence for executive teams to be able to plan out strategic initiatives.
- Key Dates / Milestones: Is there a trade show coming up? Is there a regulatory requirement that needs to be met? Is another team's progress dependent on when your team finished their work? There will always be some dates that cannot be adjusted and with enough upfront notice teams can get creative about how they can adjust the scope and the amount of effort spent on different features to deliver what is needed by that time.
- Synchronization within different departments: For any large project there will be many moving pieces with their own goals that they are trying to hit. Whether its sales, marketing, customer support, IT, etc. everyone will need to be working towards the same direction to deliver successfully. If they all have the same big picture to refer to and that they are constantly revising as new information becomes available, the teams can coordinate so that everyone can work as effectively as possible.
- Risk Identification / Mitigation: I have seen many teams that have a fixed timeline and they have been hitting their sprint goals consistently, but they then pass the halfway point of the project and realize they are not halfway to accomplishing what they had originally set out to do. Having a release plan that the team reviews regularly helps identify when teams are falling behind or if there are dependencies or other similar risks that can catch them by surprise if they are not looking ahead.
Building a Release Plan
Below I have included the basic process I have used with my teams in the past. This list is by no means exhaustive, and each of these steps can be dived into in much more detail. However, I have kept this at a high level to provide an outline to reference if you are just starting and want an idea of where to begin.
- Identify high-level goals
- Identify key dates
- Break higher-level goals into epics
- Conduct high-level estimation on epics
- Select and prioritize epics/stories for next release (use the team's historical velocity if available or something like capacity planning if the team is still learning what their true velocity is)
- Proceed with sprint planning
- Revisit the plan regularly to incorporate feedback from sprint reviews or changes in business priorities
Tips for Release Planning
- Estimating: use something like t-shirt sizing or affinity estimation to ensure that you don't spend a ton of time on estimates that will almost certainly be off or likely to change
- Frequency: if you are using a framework such as Scrum, I would recommend reviewing the release plan during the sprint review or at the beginning of sprint planning to ensure it is happening regularly
- Story Maps: a tool like story mapping can help visually lay out what the projected functionality and stories to be delivered in each release will look like
- Visibility: as mentioned earlier, it helps to make sure the release plan is always available to the immediate team members so they have an idea of where the work they are doing fits into the larger picture and to allow them to better self organize. However, it is also beneficial for the plan to be visible to other stakeholders within the organization so they can see what the general progress on the project is and to help answer the question of: "can I add this new thing in?" or "when will we be done with this?"
- Continuously Re-evaluate: it cannot be emphasized enough that a release plan should not be written in stone. New information will be discovered during the project, surprises and setbacks will happen, and priorities will shift. The release plan should reflect these changes
Although release planning is a small piece of the overall planning that occurs throughout an Agile project, making sure your teams are doing this regularly will go a long way towards making sure the project stays on track and building confidence within skeptical organizations that teams using Agile can effectively plan and deliver on higher-level goals.
What has your experience with release planning been? Have your teams been resistant to the idea? Is your process any different?
Published at DZone with permission of Daniel Barreto . See the original article here.
Opinions expressed by DZone contributors are their own.