Build overview

Introduction

This section covers the refinement of epics from the plan and implementation and validation of working software ready for operations.

This is a set of defaults for teams to use, but is not mandatory if teams have good reason to do something different (see What this is — and is not).

Inputs

• Epics
• Backlog items

Outputs

• Software running in production.

Iterations with continuous flow

The recommended default delivery approach uses a regular cadence and continuous flow.

The process described here draws on Kanban, Scrum and Extreme Programming, adding specific recommendations and choosing terminology which is commonly understood. Although not essential reading, these guides provide useful background on the principles and values which lead to these recommendations:

• Scrum with Kanban guide (January 2021), the latest version of which may be downloaded from scrum.org
• Kanban guide
• Scrum guide
• Extreme Programming rules

Recommended defaults:

• Have a daily stand-up to keep the team aligned and items moving.
• Maintain a prioritised buffer of backlog items that are ready to implement, maintained through regular refinement sessions once or twice per week.
  • When this buffer runs low (say less than 3 items, but the threshold will depend on the team) this should trigger more analysis and elaboration work to ensure team members do not run out of items that are ready for implementation. It is also recommended to set a WIP limit.
  • Priorities are reviewed and updated daily as part of stand-up.
  • There is no concept of selecting items for an iteration; items are picked up from the prioritised backlog as team members become available.
  • Effective flow is measured using cycle time and/or lead time and delivery progress is tracked at the epic level using the epic roadmap.
• Have iteration reviews and retrospectives every two weeks.
  • Teams may choose to define an "iteration goal", but this is optional and may be unnecessary since the epic roadmap provides clarity of what the current iteration covers and how this fits into the overall delivery.
  • There is no special treatment of "iteration end", in-progress work just continues. There is no concept of splitting or carrying forward items.
  • Releases are not tied to this two-week cycle and may be more frequent.

Upfront vs just in time

The recommended default is to perform refinement once or twice per week to maintain the right sized buffer. The aim is that team members will usually have items that are ready for implementation when they become available to pick up new work.

The implication is that the people who refined an item may not end up implementing it. This does require the detail on the item to be sufficiently clear so that all the necessary information is available for whoever picks the item up for implementation. While this takes some discipline, it tends to drive good practice in clearly thinking through and recording the refinement.

Reasoning

In general, it is preferred to defer refinement and do it just in time.

• More information is available to perform refinement quickly and effectively, compared to doing so longer in advance.
• There is less chance of waste from time spent refining items that never get implemented.

Exactly when "just in time" is depends on two things:

1. Delivery framework
   • If (despite the recommendation of iterations with continuous flow) you are using an approach where items are selected for the forthcoming iteration every two weeks, then detail should normally be added to items before the iteration starts. This does depend somewhat on the team's willingness to accept changes to the forecasted iteration scope. In teams where this scope is considered more of a rough guide, the bulk of detail may instead be added just in time during the iteration, on the understanding that this may change the iteration scope.
   • If (as recommended in iterations with continuous flow) you are using a continuous flow delivery approach then this opens the possibility of doing refinement more incrementally, even potentially on-demand as team members become available to pick up new work (however, see points below).
2. People availability
   • Refinement requires at a minimum: input from the product owner and technical and test representatives. In many cases, there will be key individuals who may be needed to refine any particular item. If these individuals are unavailable then refinement cannot be done.
   • Pulling team members away from their implementation and validation work to do refinement creates an interruption that can impact effective delivery.
   • For these reasons, it is recommended not to perform refinement on demand, but to do so on a regular schedule, once or twice weekly. This gets the best of both worlds: the buffer is small, avoiding most of the downsides of refining too much too far in advance, but the regular routine makes it easier to ensure the right people are available without unplanned interruptions to delivery work.

Iteration review

The recommended default is to have an iteration review every two weeks.

• The whole team should be present, including the Product Owner and potentially SMEs.
• This is a chance to get feedback on, and take stock of, delivery.
• Demonstrate any new features completed since the last iteration review.
• Optionally, give early sight on in-progress features for feedback, but be clear that these are not complete.
• Use a written report or slide deck to provide structure for the review which includes:
  • A list of continuous improvement changes made in this iteration, often things identified in the last retrospective.
  • Top risks and issues to be highlighted from the risk and issue logs.
  • Any impediments.
  • Top decisions made this iteration or open and requiring resolution.
  • A snapshot (e.g. photo or screenshot) of the epic roadmap.

Valuable reviews

The iteration review is most valuable when the team gets feedback and fresh insights from stakeholders. Stakeholders may have visibility of things the team may not routinely see, including things like other parts of the business, high-level strategy, or external market factors.

Indicators that reviews are valuable are:

• Team and stakeholders have a working discussion on how the iteration deliverables help (or not) to meet business goals.
• Stakeholders provide information on changes that help inform priorities for the team, such as: market, timelines or budget.

Watch out for

• Make sure the review is collaborative and all participants are engaged to ensure stakeholders and the team gain actionable insight from each other. Don't allow it to become just a presentation, especially if it involves long slide decks which are laborious to produce and do not increase engagement.
• Be wary of a lack of interest by external stakeholders, meaning the team is deprived of potentially valuable information. This may also suggest the direction of the product needs to be re-evaluated.
• Ensure learnings from the review are acted upon, for example by updating priorities or product direction when needed.