Planning Workshops

Purpose

A planning workshop works out what value can be delivered over an agreed period and secures the team's commitment to that content. The Agile Extension to the BABOK Guide credits it with two further effects: collaboration with the customer in every period and revision of the plan on what feedback from the field brings to light.

The output of the session is a dated commitment: a goal for the period, the list of items chosen to reach it and the plan of work the team sets itself. The Agile Extension distinguishes two levels of session. The first is held before the iterations start and covers the current release, the set of features delivered to one and the same deadline. The second addresses a single iteration or a designated slice of the backlog.

Backlog refinement, an activity of backlog management, normally precedes the session: the size, scope and complexity of the items are worked on there. Planning assumes that work is done.

Place in the workshop family

The workshop as the BABOK Guide defines it is the general form of the facilitated session: a representative group of stakeholders, a defined goal, interactive and collaborative work, a defined work product and a facilitator. In that form it serves scoping, modelling, elicitation or requirements validation. Where the general workshop takes whatever goal the room assigns it, the planning workshop always has the same one: decide what will be delivered over a period and commit to it. Every planning session is therefore a workshop in the general sense; the reverse does not hold.

Use

When to use it

• Opening an iteration: set the goal for the period and select the items the team commits to finishing.
• Starting a release: sequence the features across the whole release before the first iteration.
• Choosing between initiatives: keep the ones that serve the organisation's goals and allocate resources between them.
• Several teams on one product: make the dependencies between items visible before any commitment.
• Shifting priorities: feedback from the period just closed redirects the content of the next one.

When not to use it

• Backlog neither estimated nor ordered: the session turns into refinement; prepare it with backlog management and estimation.
• Decision without a delivery commitment: scoping or requirements validation is run as a workshop in the general sense.

Description

The two parts of the session

The Agile Extension splits the session in two. In the first part, the what, the product owner sets out the goal, the expected outcome, the target date and the highest-priority backlog items, then clarifies the details the team asks for and checks alignment with the goals being pursued. In the second, the how, the team discusses how each item can be finished and what it needs to get there.

In practice, a team that opens with the how is planning content nobody has settled yet, and the product owner ends up weighing business value in the middle of a technical discussion. If the how uncovers a cost the what had not anticipated, the selection reopens during the session.

The five elements

The estimated and ordered backlog is the main input. The Agile Extension gives business analysis practitioners the estimating and the ordering of the items. A session handed an unordered list spends its slot ordering it instead of planning.

Team velocity, the throughput observed over previous periods, keeps the ordering realistic: it bounds what can be accepted. In Kanban, work-in-progress limits set that bound and the session then serves knowledge sharing rather than an iteration commitment.

The iteration goal or the batch of features is a subset of the release goal or of the roadmap. An item that does not serve that goal waits for the next period, even when it is ready.

Item selection belongs to the product owner, who takes the goal and the highest-priority items from the release plan, weighing value against the velocity available. The Agile Extension puts work that produces no feature into that selection too: defects, environment setup, research work, management work. Leaving them out of the plan means planning for capacity the team does not have.

Task planning breaks each selected item into work that can be assigned to members of the team. That breakdown turns a list of items into a plan a team can commit to.

The three horizons

The technique is practised at any planning horizon, with a purpose and a level of detail that follow the horizon. The Agile Extension sets it out horizon by horizon: at the Strategy horizon the session produces a shared understanding of why a new initiative exists; at the Initiative horizon, of how the solution will be built.

At the Delivery horizon the session is held at the start of every iteration, in a slot the team sets for itself to go through the next batch of items. The Agile Extension asks the team to understand the goals of the iteration and hold to them, together with the value attached to the minimal marketable feature being targeted, the business stakes and the way the stories are split.

The Agile Extension fixes no duration at any of these three horizons. The one numeric ceiling comes from Scrum and applies to the Delivery horizon alone. A portfolio or release session is therefore framed by its agenda and by the availability of the people who decide.

The Delivery horizon: Sprint Planning

In Scrum, the planning workshop of the Delivery horizon is Sprint Planning. The event initiates the Sprint by laying out the work to be performed, and the resulting plan is created by the whole Scrum Team. The Product Owner makes sure the attendees are ready to discuss the most important Product Backlog items and how they map to the Product Goal. Other people may be invited to give advice.

The Guide ties the Developers' confidence in their forecasts to three things they know: their past performance, their upcoming capacity and their Definition of Done. The Sprint Goal, the Product Backlog items selected and the plan for delivering them form the Sprint Backlog.

The Guide caps the event at eight hours for a one-month Sprint; for shorter Sprints it is usually shorter. The Scrum Master sees to it that the events take place, that they are positive and productive and that they stay inside their time box. The Guide does not use the word facilitator, and it describes neither scribe nor timekeeper: running the session belongs to the team.

What makes the session fail

The incomplete team

The technique asks for every member of the team to be present. An absence is paid for twice: the session stops while somebody chases the missing information, then the plan is redone when the absent member comes back with a constraint nobody had seen. The Agile Extension notes that the problem gets worse for distributed teams and for teams whose members work across several teams. Where a common diary is impossible, the one workable defence is preparation: the absent member's constraint is collected before the session and carried into the room by someone present who answers for it.

The misunderstood backlog

The Agile Extension lists insufficient understanding of the backlog among the limitations of the technique, because it leads to a poor plan. The room spends the first hour describing what an item does instead of choosing whether it goes in. The session becomes refinement, useful work that has its place elsewhere and that here eats the time meant for the decision.

Too little time

Too short a slot pushes clarification of the goal and of the content into the days that follow, outside the session and without the product owner.

The goal left open

At the Delivery horizon, the Scrum Guide requires the Sprint Goal to be finalised before the end of Sprint Planning. A team that leaves the session with a list of items and no goal has lost the thing that lets it weigh an unforeseen event against the intent of the Sprint. It will treat every incident as a scope negotiation.

AI considerations

Before the session, a language model works on the already ordered backlog. It spots the items whose description is too thin to plan work from, the ones that overlap and the ones that depend on an item nobody selected. From the items at the top it proposes wordings for the iteration goal, which the room rewrites. After the session it puts the task plan into shape and checks that every selected item ties back to the stated goal.

What the model does not know is what decides the session. Capacity for the coming period depends on absences, on-call duty and interruptions that only the team knows about. Pressed for a number, a model produces a plausible one that comes from no record, and the plan inherits a precision it does not have. The commitment belongs to the people who will do the work: a selection that arrives ready-made removes the discussion of the how, which is half the session. A backlog carries customer segments, amounts and regulatory constraints that have no business leaving the company, and they are stripped out before anything goes to a public model.

Examples

The digital banking unit of a retail bank in Suisse romande, supervised by FINMA, is planning the launch of instant person-to-person transfers in its mobile app. The same technique is run at all three horizons, and the output of each session becomes the input of the next.

No session decides in place of the next one: the budget allocation says nothing about the order of delivery, and the release plan says nothing about which tasks fit in the sprint about to open.

The Delivery horizon session runs for two hours, a duration the team set for itself under the ceiling of the Scrum Guide.

Visualisations

The three-tier cascade is the drawing that carries the technique. One panel per horizon, each showing its session and the output it leaves behind, linked by a chain of arrows in which the chosen initiative feeds the release plan and the release plan feeds the Sprint Backlog. The Delivery panel names Sprint Planning with its three topics, and its two outputs run on into the sprint that starts.

Cost

Tools

Backlog management tools (Jira, Azure DevOps, GitLab and their equivalents) hold the input and the output of the session: the ordered and estimated backlog before, the selected items and their tasks after. They also produce the record of throughput delivered in previous periods, the source of the velocity used to bound the selection.

Collaborative whiteboards (Miro, Mural, FigJam and their equivalents) serve the Initiative horizon: sequencing features across several releases is done by moving cards around, an operation the list view of a backlog tool makes painful.

A wall and cards remain the fastest setup for a co-located team at the Delivery horizon, provided the plan then goes back into the backlog tool, the only place where it survives the week.

A spreadsheet is enough at the Strategy horizon, where the session handles a dozen rows: candidate initiatives, budget in CHF, capacity assigned, target metric. Tying each row to an existing metric is what separates an allocation from a wish.

Video conferencing with a shared board is what a distributed team falls back on. It carries the session, without making up for a missing member.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.8 Planning Workshops: the purpose of the technique, the commitment over an agreed period, the two levels of session and the split into two parts, the five elements, among them the estimated and ordered backlog, velocity and task planning, the use at the three planning horizons, the Kanban case and the limitations stated, incomplete team, insufficient time and misunderstood backlog.
• IIBA, Agile Extension to the BABOK Guide, §4.7.1 and §5.7.1, the techniques by planning horizon: the allocation of resources between initiatives and the reason a new initiative exists at the Strategy horizon, the shared understanding of how the solution will be built at the Initiative horizon.
• Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020), section "Sprint Planning": the instance of the Delivery horizon, its three topics, the Sprint Goal finalised before the end of the event, the Sprint Backlog, the ceiling of eight hours for a one-month Sprint and the role of the Scrum Master in holding the event.
• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.50 Workshops: the general definition of the facilitated workshop, cited to place the planning workshop as a specialised member of that family.