How To Track Success Of Release Planning Or PI Planning?
Summary
“When will you deliver the project?”
“How can you ask that question? We are Agile”
Typical conversions in a project, isn’t it? Release planning or PI planning is common place practice for scaled scrum teams. Typically this planning is done for a duration (quarter) or for specific number of sprints (5 sprints). Available work in the product backlog is distributed within teams and tagged to specific sprints. Work is priorities according to target release (fix version). Typically before this release planning the available work is already prioritized in the product backlog. The premise of this article is to discuss how to track the success of release planning after the actual planning meeting. What are the appropriate metrics and reports to be used to justify plan versus actual and the ROI for management for investing in release planning meetings. (Release planning meeting could be huge investment, e.g. 100 members team in planning meeting for two days is 1600 hours; plan logistics etc.).
Release Planning/ PI Planning: Definitions
PI Planning
PI planning is formal event from scaled agile framework safe.
Source: http://www.scaledagileframework.com/pi-planning/
Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and vision.
Release Planning
Source: https://help.rallydev.com/glossary#release_planning
A commitment to a plan for delivering an increment of product value. It is a collaborative effort involving scrum masters, product owners, delivery teams, and stakeholders.
At a very high level, scrum team get together to plan their work for next few sprints. This is a high level plan and this plan is not an alternative to sprint planning meeting.
Following are some knowledgeable articles if you are interested to know more about Release Planning or PI Planning best practices. In this article I am going to discuss how to track the success of such planning after the planning meeting.
https://www.atlassian.com/blog/agile/product-managers-guide-release-planning
http://www.scaledagileframework.com/pi-planning/
Release Planning Success Factors
For Product Stakeholder: Alignment with Business Goals
Release planning provide opportunity to product stakeholders to align their vision with the plan. I am using product stakeholder encompassing term to cover all the parties who has best interest for the product at their heart. These includes, product owners, product managers, clients, customers, higher management etc. Release planning can be the driver for cascading the business goals into implementation plan for next few months. Product stakeholders should utilize this opportunities to see their vision turning into reality sprint by sprint.
For Scrum Teams: Plan Work for Next Few Sprints
For scrum teams release planning provides the opportunity to define their roadmap for next few sprits. Typically during the sprints the development team members are heads down working on achieving the sprint goal; release planning provide them the chance to take a look that the overall business value they are delivering over the course of next few sprints. This provides them the bird’s eye view to look at the upcoming work and align themselves with the bigger picture.
For Scrum of Scrum: Identifying the Cross Team Dependencies and Risks
Typically release planning is chaotic activity. Over the period of couple of days multiple teams come into a single room to plan the work. Through discussion dependencies are identified and minimized (in order to have more independent stories). Also, risks come to the surface which can be tracked, mitigated or accepted.
For Resource Management: Capacity Planning
The release planning meeting are opportunities for resourcing managers to do capacity planning for next few sprints. In the release planning meeting the available work become evident and can be compared with available capacity. This is to help with no boarding new team members and team, collapsing or merging any teams.
Metrics/ Reports to Track Success
Working software is the primary measure of progress. —Agile Manifesto
The most important things cannot be measured. The issues that are most important, long term, cannot be measured in advance. —W. Edwards Deming
That’s the problem with so many organizations around entrepreneurship. They’re driven by metrics that don’t matter.” – Brad Feld
Metrics are agreed-upon measures used to evaluate how well the organization is progressing toward the portfolio, large solution, program, and team’s business and technical objectives. But metrics are indeed important in the enterprise context. In today’s data-driven world we rely on metrics extensively. Large corporations will often take “Key Performance Indicators”, and other such measurements, to inform them about conditions and trends. However usefulness of a measurement must therefore be assessed critically. We have come to appreciate the danger of measuring the wrong thing, or perhaps of measuring the right thing only to correlate it to the wrong conclusion. The Scrum framework is founded on such empiricism, but it does not prescribe any particular metrics that we might use. The prescription of specific practices, such as which tools or metrics to use, would constrain Scrum and reduce its general utility.
Release Burn-Down Chart
Forecasted vs. completed or Planned vs. Delivered burn down charts are the most common chart used by the Scrum Team compares the number of story points planned for the sprint against the number of story points actually delivered in the sprint. It is used to measure the progress of the sprint team’s ability to understand the work to be done and estimate this effort accurately. After the release planning meeting is over, the team has a fair idea of the number of sprints and the user stories to be completed for that release. The release burn-down chart shows the progress toward the release timebox. It’s used to track the work planned for a release against the work completed. The horizontal axis of the release burn-down chart shows the sprints within the release. The vertical axis shows the amount of work, in story points, remaining at the start of each sprint. The ideal line indicates the path of progress, without any hiccups and obstructions, while the actual line indicates the current progress of effort or the actual work remaining. Although the release burn-down shows the progress toward the release timebox, it does not reveal which features are lagging behind. Other drill down reports can be used for this purpose. When a sprint is complete, the product owner or the business sponsor will be able to determine whether the team is on track.
Business Goals Report
This report can tie the business goals with release and timeline. Where X axis is the calendar timeline and Y axis is the release planned. This report is to visualize the vison turning into reality release by release. This is cross report between product roadmap and release plan.
Kanban Board
The primary purpose of the Kanban board is to ensure that Epics are weighed and analyzed before reaching a release planning boundary. This way, they can be prioritized appropriately and have established acceptance criteria to guide the execution. This is Epic level board and stories are not tracked on this board.
Release Backlog
A release is a set of product increments that is released to the customer. Releases are defined by date, theme, and planned feature set.
Out of scope-schedule-budget iron triangle, consider scope as the variable. When a release date is set in stone, and an increase in budget is unlikely and usually has no positive effect on a release, the scope is the only variable that can make or break the release date.
All teams should commit to the same rhythm of sprint and releases. When all teams work to the same rhythm it helps in the planning activities.
Release backlog is similar to sprint backlog but scoped across multiple team marching towards the same releases. This is cumulative product backlog of all the stories for all the planed in a single release planning meeting.
Dependencies Graphs
Release planning is an excellent event to identify the cross team dependencies with respect to epic and stories. These dependencies can be visualized in the form of dependency graph at different level. There is common practice to define story decencies for one scrum team. At a macro level, the dependency graph can be used for across team epic level dependencies.
Story Dependencies
Team Epic dependencies
Capacity Planning
The release planning can also be an opportunity for capacity planning. The total planned work will need set different skills to be available on the ‘cross functional’ scrum teams to be delivered as per the plan. Following is one sample graph to showcase the capacity gap for each skill across the planned work in story points. The visualization of capacity gap can lead into ramping up new team or reshuffle, collapsing or merging some team. The resourcing manager can take a clue hiring new people or adjusting the available resources.
Release Retrospectives
A release comprises many sprints and could last three months or even more, depending on the organizations release cycle. A sprint retrospective provides an opportunity to inspect and adapt the sprint cycle, to look back at how the sprint was and discuss as a team ways to make improvements in the coming sprints. Similarly, a release retrospective is an opportunity to inspect and adapt the release cycle rather than the sprint cycle. The start and end dates for the inspection and retrospection would vary according to the release cycle. Release retrospection is not a formal scrum event, but it can help similar way for scaled scrum team. Release retrospective can have following agenda.
What went well since the last release planning meeting?
What could be improved?
What will we commit to improve until the next release planning?
Team can collectively pick one experiment that they want to execute until the next release cycle. The must come up with hypothesis and success criterion for the experiment.
Conclusion
Release planning (or PI planning) is an important event in a scaled scrum implementation. This event provide opportunity to stakeholders to plan their piece of pie. It is equally important to track the success of release planning as it is to participate in the couple of days release planning meeting. As with the saying goes ‘what cannot be measured does not exist’, it is important to choose the appropriate metrics to demonstrate the success of release planning. Inappropriate metrics selection can lead to false conclusions.