ManagementSubsection
Decomposition
Turning something too big to start into pieces small enough to finish — and keeping the reason for each piece attached to it on the way down. Four topics covering the two traditions that rarely meet: work breakdown from project management, and user stories from product. They answer different questions, and knowing which one you are in stops most arguments about how detailed a plan should be.
What is inside
Every page in this group, with what each one covers.
- Work Breakdown StructureDeliverables, not tasks: the dictionary, control accounts, planning packages and rolling wave planning.Deliverables100% rule
- User StoriesWhat a story is for, acceptance-criteria formats, story mapping, spikes, and what points actually measure.INVESTSlicing
- Epics, Features, TasksThe hierarchy every tracker names differently, with Jira, Azure DevOps and SAFe mapped against each other.HierarchyTooling
- OKRGoals that are not a task list: committed versus aspirational, the cadence, guardrails, and OKR against KPI.OutcomesQuarterly
Where to start
- Writing a backlogUser stories, then epics and features — the hierarchy makes far more sense once you know what sits at the bottom of it.
- Planning a fixed-scope projectWork breakdown structure. It decomposes deliverables rather than work, which is the distinction that makes estimates hold.
- Your goals are a task listOKR, specifically the split between committed and aspirational — that is usually the missing piece.
Elsewhere in the section
- ManagementIT project management is the set of decisions that turn an intention into shipped software: what to build, how to cut it into work that can actually be finished, how the team runs itself week to week, and how the result reaches users. This section covers 21 topics in five groups — product management, decomposition, methodologies, the release process and the formal frameworks — and each page gives the trade-off behind the choice rather than a summary for a certification exam.
- MethodologiesHow a team decides what to build next, in what order, and how it knows when something is done. Nine methodologies, from the two most teams actually run to the four that exist because one team stopped being enough. Each page describes what the framework actually defines — every ceremony, every role, every artefact — rather than summarising it, and says plainly where it stops working.
- Product ManagementDeciding what is worth building at all, and being able to tell afterwards whether it worked. Three topics that follow each other: finding out what people need, choosing what to do about it in an order you can defend, and measuring the result without fooling yourself. The hardest part of all three is declining things, which is why each page covers how to say no as well as how to choose.
Found this useful?
Share it with someone who is working on the same problem.