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 StructureA finished WBS for an IT project, then the 100% rule, the dictionary, control accounts and rolling waves.Deliverables100% rule
- User StoriesSixteen common stories rewritten, then acceptance criteria, example mapping, nine ways to split and story maps.INVESTSlicing
- Epics, Features, TasksEvery level on one screen and one epic taken down to tasks, then Jira, Azure DevOps and SAFe side by side.HierarchyTooling
- OKROne team’s OKRs for a quarter, finished, then outcomes, guardrails, how a score is computed and the line to pay.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 25 topics in six groups — product management, decomposition, methodologies, the release process, the formal frameworks, and the craft of running a project rather than a method for running one — 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.