Workflow Management
Workflow Management describes the way that our solutions are broken down into a hierarchical structure.
Throughout the problem lifecycle we break large solutions to problems down into small value increments, which are in turn broken down into the smallest independently deployable chunks, each of which require various specific tasks to be performed.
The objective of workflow management is to provide an adaptable but repeatable structure that reflects this relationship between problems, solutions, value increments, and deployments.
Workflow Hierarchy¶
The workflow hierarchy as 4 layers:
- Strategic:
- Outcomes, which belong to a Roadmap Item (in Product Board)
- Features, which belong to Outcomes
- Backlog, including:
- Backlog Items, and may relate to Bugs
- Spikes, which belong to Features, and may relate to Bugs
- Bugs, which belong to Features, and must relate to Backlog Items
- Work, including:
Planning Mechanisms¶
Each layer has its own planning mechanism:
- Delivery Modelling is used to model the delivery of Outcomes, and therefore show how the roadmap will be progressed. Looking ahead around 12 months.
- Delivery Planning is used to plan the delivery of Features, and therefore show how Outcomes will be delivered. Looking ahead around 6-12 sprints / 3-6 months.
- Runway Planning is used to plan the implementation of Backlog Items, and therefore show how Features will be delivered.
- Sprint Planning / Iteration Planning is used to plan the tasks that must be performed in order to implement a backlog item. Using this structure will mean that there is an inherent link between each plan.As estimates and plans are produced for lower layers, their parent item’s estimates and plans must also be updated.
Illustrative only
Actual plans will contain significantly more contextual information than is shown in this image, such as dependencies, estimates, ownership, status, risks…
Workflow Item Definitions¶
Outcome¶
An Outcome is a generic term for a sub goal of a product roadmap objective. The term Outcome could be replaced by “Milestone” or “Epic”. We use the term outcome because it carries more meaning than epic, and is more flexible than milestone. Some Roadmap items may only have one Outcome, while others may have many.
Outcomes must belong to a roadmap item.
An Outcome should describe a manageable target centered on the user value and describes the impact that the business desires from the completion of the Outcome. It should not describe an output. The primary audience for an Outcome is Leadership, Product Managers, UX and Engineering Leads, however all members of the team should read and understand Outcomes.
The following fields exist on an Outcome:
- Summary - This should be a short (1-2 sentences) narrative of the value this outcome will deliver. It is an extension of the title and should outline the user impact and outcome.
- Description - More detailed information of the user impact and/or outcome of this change. Outlining success criteria and any measurable ways of knowing when this outcome is complete should be included in the description.
- ROM Rationale - Information that explains why the ROM Outcome Size has been set to the value it is. This field is mainly used for technical notes describing things that need to be implemented or tested that provide some reasoning.
In addition to these fields, any RAID (Risks, Assumptions, Issues and Dependencies) should be added as child items to an Outcome.
Feature¶
A feature is a generic term for a sub-goal of an Outcome. Features must be independently usable and valuable. Features may require changes to many platforms/repositories.
A feature is not necessarily a functional or user-centric value improvement. Whilst some features may be described as “user stories”, a feature can also describe non-functional improvements.
Features can be categorised by the type of investment or purpose, i.e. is this maintenance or added value? If this is maintenance then which type: perfective, preventative, adaptive, or corrective (bugs are generally corrective maintenance).
Features must be a child of an Outcome.
A Feature should describe a high-level piece of functionality that directly contributes to an Outcome. The title should ideally use "user-facing" language and should not be technical. The audience for a Feature is Leadership, Product Managers, UX and all Engineers.
The following fields exists on a Feature:
- Description - Describes what the feature is, what capability is being added and who it is for.
- Requirements and Specifications - What is required for this Feature to be considered done. They should not be overly detailed or even following Given, When, Then syntax, this detail belongs in Backlog Item. For example, "Cross Site Scripting Attack Vulnerability tests pass" would be an acceptable requirement in a Feature.
- Design and Implementation Plan - Any information related to the technical work that needs to be done for this feature. Often links to ADRs, designs or other pieces of documentation would be included in this field. Low-level design and implementation details should be written in individual Backlog Items.
When a Feature is viewed, it should be clear how far the feature has progressed by glancing at the child items and seeing their status.
Backlog Item¶
A backlog item is the smallest operational increment that can be made.
A backlog item should only affect a single repository, for example.
An operational increment must be independently deployable and testable, it must not cause damage, but individually may not be usable or valuable. Each feature would typically require several backlog items.
Backlog items must belong to a feature, and may be related to a bug.
Spike¶
A spike is a technical investigation used to remove uncertainties around technical viability and feasibility. Spikes seek to answer specific questions. Then outputs of a spike will include a documented summary of the learnings, and may also include a proof of concept.
Bug¶
A bug is an issue identified within production applications. A bug occurs when a feature does not behave as expected.
Bugs must belong to a feature - in principal a feature's requirements or specifications are not being met.
A bug must relate to at least one backlog ite. It may affect multiple repositories, and may therefore require multiple backlog items.
Task¶
A task describes any discrete piece of work. Each backlog item will require several tasks in order to produce an operational increment. These tasks may span multiple disciplines such as development, testing, design, documentation, and so on.
Task items must belong to a backlog item, and may relate to a Defect.
Defect¶
A defect is an issue identified during the development lifecycle.
Defects must belong to a Backlog Item, and will relate to at least one task.