How do we ensure Features are “ready” for a Big Room (PI) Planning event?
As we implement Lean Portfolio Management systems or begin quarterly planning, it’s crucial to ensure we have the items we need to work on “ready” for Big Room (PI) Planning event. Often we see a situation where, with the best intention in the world, that teams are struggling to understand the work as we change the process to incorporate portfolio thinking. Whether we have Features as a result of approved Portfolio Management efforts, or Features that result from more local, program level decision making, it helps all concerned if we can develop new Features in a systematic way.
I first came across the idea of a T-minus calendar for Feature Readiness when working with Rally. The idea is that we set out expectations of how ready features are expected to be based on timing with regard to an upcoming Big Room (PI) Planning event on date T. An example of this kind of calendar is:
- T minus 9 weeks: Next PI’s high pass. List of key Features to be considered for the next PI based on in-progress and expected Epics. Update (outcome-based) Feature Roadmap (as well as impact on Epic Roadmap):
- Current Quarter (PI X): Based on commitment made at recent PI Planning event
- Next Quarter (PI X+1): Based on high level pass at this stage
- Next Half Year (PI X+3 and PI X+4): Based on remainder Features that we think might be done in the future (note: be super conservative - as Nils Bohr says “Prediction is difficult, especially about the future”)
- T minus 8 weeks: Epics broken down into Feature “ready” for the Feature sizing Team (assumes we are not going to get all Team involved at this time).
- Assumes you have high-level view of what will be needed to get the Feature done. E.g. Team that is expected take on the work, dependencies (other Teams, vendors, specialised skills), and so on. Now is the time to start working these issues so we can improve our PI Planning process.
- Assumes you have a “Definition of Ready” for a Feature which answers the question “what information do we need in order to provide a good Feature estimate?”
- Expect there to be significant collaboration here (stakeholders, POs, UX, support, etc.). Divergent thinking to generate possible ideas; convergent thinking to settle on some Epics.
- T minus 7 weeks: Feature estimates due. Review impact on Feature (and Epic) Roadmap with leadership.
- Note: this might also be a time to update leadership on status of current PI
- T minus 6 weeks: “Why” meeting with the Teams. Present upcoming Features to the Team, explaining why these things are there. Idea is to socialize the Features (and their related Epics) well before the PI Planning event.
- T minus 4 weeks: Feature estimates are updated based on feedback from the Teams
- T minus 3 weeks: Feature breakdown begins, especially as need to do mock-ups, research, etc. so that we can move smoothly implementation when we get into PI Planning event
- T minus 1 weeks: Feature (and Epic) Roadmap updated based on final estimates. PI System Demo. Innovation. Inspect and Adapt.
- T week of: PI Planning event and Iteration Planning for first Iteration of the next PI.
The best approach to implementing such a calendar is to make the calendar public, so that everyone is aware of expectations and can hold each other accountable. The calendar should be updated to reflect your organisation’s terminology and what is possible in your organisation.
A word of warning. Being ready in this instance does not mean that we have everything documented in detail, scope fully specified. The purpose of being ready for a Big Room (PI) Planning event means that we have had the appropriate level of collaboration between those requesting the work, and those who will do the work. In particular we are trying to avoid premature convergence on the problem we are working. This is when, in our rush to declare something “complete”, we build a single solution to a problem and pretend that is the only potential solution to that problem. In general we are trying to set things up so that we can explore options, learn, and therefore come up with a plan that optimises a number of inputs. In the final analysis, being ready means “the teams understand what is expected”.