Skip to main content

Planning

Introduction​

This section covers forming and evolving the epic roadmap and risk log, and feeds into the build activities.

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).

Delivery process overview

Inputs​

Outputs​

Epic roadmap​

Essential reading: The process for creating and maintaining an epic roadmap is described in Epic Roadmap.

Epic roadmap

  • Create and maintain an epic roadmap that covers the next 3–6 months.
    • What is going to happen more than six months in the future is inevitably speculative. If there is a need to forecast further then it is usually best to do so at an explicitly lower granularity, such as identifying goals for each quarter, rather than extending the epic roadmap.
  • Hold regular planning sessions to ensure the roadmap stays up to date; default to every two weeks.
  • Use T-shirt sizing for epics: XS, S, M, L, XL, with each size representing a doubling of effort.
    • As well as the amount of work to do, represented by the T-shirt size, also indicate the degree of uncertainty caused by complexity or unknowns: high, medium or low. For example, "S/H" for "small size, high uncertainty" or "M/M" for "medium size, medium uncertainty".
  • Use a lightweight tool to represent the roadmap such as physical sticky notes or an equivalent online tool such as Miro.
    • Do not put epics in your issue tracker, except possibly just in time as they are broken down into backlog items, as a way to group those items. Issue trackers create unnecessary overheads and are not well-suited to representing an epic roadmap.
    • Epics should be small enough that the title alone clearly defines the scope without the need to keep additional notes, so a simple "sticky note" approach works fine.
    • The estimate can be indicated as part of the title as shown in the diagram.
  • Split epics until you can comfortably order them with the intention of fully completing each epic before moving onto the next.
    • This often means getting more specific. For example, a "Login" epic may be split into "Log in with username and password", "Password recovery" and "Log in with Google".
    • These split epics can be prioritised individually, and each will be easier to understand and estimate.
    • Split epics until you expect to be able to deliver a small number per iteration.
    • A small number of epics may be in-progress at any one time, but the aim should be to keep this work-in-progress limit low.
    • Do not use epics as a loose grouping of related backlog items; treat them as individually-deliverable chunks of functionality. With careful wording, it is usually clear which epics relate to each other.
  • Have a column for each iteration for the next 3 months (i.e. 6 iterations), and a column for each month thereafter to indicate the increasing uncertainty further into the future.
  • In each column, show the epics which are expected to be completed in that time period.
  • Also in each column, show the goals which will be delivered in each time period.
    • Goals represent thresholds to judge the product against when deciding whether it is ready for a particular business-relevant event. Typical examples are: "Ready for pen test" and "Beta launch".

Cone of uncertainty​

The timeline on the epic roadmap will have a high degree of uncertainty early in delivery because the actual time taken to deliver each epic will vary widely relative to the estimate. Over time this uncertainly will reduce as more is learned, and estimates will become somewhat more accurate. Have open and honest conversations about the relative confidence of forecasts and avoid committing to dates when uncertainty is high. This is often visualised as a "cone of uncertainty".

Cone of uncertainty

[Image adapted from Agile In a Nutshell]

The numbers on the y-axis highlight an important point that partially explains why deliveries often overrun relative to expectations: research has shown that there is a roughly equal likelihood that the actual time will be four times more than the estimate as that it will be a quarter. So the ratios are the same, but of course, the difference in absolute terms is much larger for over-estimates (4 − 1 = 3) than under-estimates (1 − 0.25 = 0.75). On average, we see that we should expect an approximate under-estimate of 3 − 0.75 = 2.25, which roughly corresponds to the "double the estimate" heuristic. However, see the further reading material for a more in-depth discussion of this and important caveats!

Further reading:

Ordering the roadmap​

The product owner decides the order of epics in the roadmap, with input from the whole team and from outside the team.

The Weighted Shortest Job First technique can provide a useful guide on what to consider, especially when trying to compare the relative priority of different types of epics, such as user features and maintainability or operability features. It is not usually necessary to apply the method formally; using it as a way to structure your thoughts is usually enough.

Weighted Shortest Job First technique​

The Weighted Shortest Job First (WSJF, pronounced "Whizz-Jiff") method breaks down value into several components:

User-business value. What is the relative value to the customer or business? Do our users prefer this over that? What is the revenue impact on our business?

Time criticality. How does the user/business value decay over time? Is there a fixed deadline? Will they wait for us or move to another solution?

Risk reduction/opportunity enablement value (RROE). What else does this do for our business? Does it reduce the risk of this or a future delivery? Is there value in the information we will receive? Will this feature enable new business opportunities?

These are combined to calculate a priority score for each item:

priority = (value + time_criticality + RROE) / estimate

Risks and issues​

  • Keep a lightweight risk log and issue log.
  • Review both regularly (default every two weeks) with the aim to promptly resolve risks and issues.

Risks​

Keep a lightweight risk log. A risk is a thing that might happen, and which would negatively impact our ability to deliver our goals. An example risk could be:

The Beta launch could be delayed if visual designs are not available by the end of iteration 3.

The recommended properties for a risk are as follows:

  • Unique ID: for ease of reference.
  • Title: of the form "<Bad thing which could happen> if/because <cause>."
  • Date raised.
  • Likelihood: how probable is it that the bad thing will happen?
    • This is just to provide focus, so an arbitrary 1–5 scale is fine.
  • Impact: how bad would the thing be if it happened?
    • This is just to provide focus, so an arbitrary 1–5 scale is fine.
  • Owner: the person primarily responsible for resolving this risk.
  • Resolved date: blank for active risks.
  • Notes: Mitigation and log of actions.

Issues​

Keep a lightweight issue log. If the bad thing described in a risk ends up happening, it becomes an issue, which needs to be mitigated as far as is possible. An example issue and its corresponding mitigation could be:

Issue: The product is not ready for Beta launch on the originally-planned date because designs were not ready in time.

Mitigation: Beta launch date postponed by two iterations and communicated to users.

Recommended properties of an issue:

  • Unique ID: for ease of reference.
  • Title: of the form "<Bad thing has happened> because <cause>".
  • Date raised.
  • Impact: how bad is the thing?
    • This is just to provide focus, so an arbitrary 1–5 scale is fine.
  • Owner: the person primarily responsible for mitigating this issue until it is closed.
  • Closed date: blank for open issues.
  • Notes: Mitigation and log of actions.

Why not RAID?​

Your customer may prefer to use a "RAID log", where RAID stands for Risks, Assumptions, Issues, and Dependencies. This is OK, but if you have the choice the recommended default is to express everything as either a risk or an issue. This helps to keep things simple, and keeps focus on the effect, pre-empting the question "so what?"

For example, consider the assumption "Team size will be consistent throughout Beta delivery". Phrasing this assumption as a risk, we get "Beta launch could be delayed if team shrinks during delivery". Reframing assumptions as risks forces some thought around what happens if the assumption is ultimately proven wrong, and so is a more useful approach.

Similarly, dependencies can also be phrased as risks. Rewriting the dependency "Designs will be ready when the engineers need them" as a risk, we're left with "Beta launch could be delayed if visual designs are not available by the end of iteration 3". Framing the original dependency in this manner forces us to think about and express the problems that will occur if the dependency isn't satisfied.

Tips for success​

It is easy to waste time "managing" risks and issues without taking positive steps to resolve them. Think creatively about how to side-step or work around them rather than letting them get in your way. Collaborate across teams when necessary and offer to lend a hand. The focus should be on keeping the number of open risks and issues low. Work should be actively ongoing on each open item. If an item is to be accepted without action it should be closed, to avoid wasting time in future review sessions.

Public page
21st September 2022