Loading
Project tool documentation explains the board. These explain the decisions the board cannot make for you: what to estimate, what to promise, when to escalate and what to absorb.
Each ends with something to avoid, because most delivery failures are things somebody did on purpose for a reason that seemed good at the time.
Sequenced, not alphabetised. Each one ends with something configured.
The recurring argument is that measurement changes behaviour, usually for the worse if you point it at people. Utilisation, velocity and estimate accuracy are all useful for planning and corrosive as targets.
Estimating and reading live margin are the two that pay for themselves fastest, because both replace an argument with a number that has its workings attached.
Scope change is the one most teams know they handle badly and have not fixed, because the fix is a conversation rather than a setting.
Every guide is written to be finished rather than to be impressive: the screen each decision happens on, and the thing that goes wrong if you skip it.
Loop tools →If you are new to Loop, read estimating and planning, then time tracking people will use. Everything else depends on hours being logged honestly.
If margin is your problem, read managing scope change first. Absorbed changes are usually where it went, and they are invisible until they are logged.
No. They are written to be useful against whatever you run today. Several describe decisions that apply to any loop-shaped system, not just ours.
Each has an owner and a review date. Where something has changed, the guide is updated rather than supplemented, so there is one current version rather than a thread of corrections.
Because the limits are the useful part. A guide that recommends everything is a brochure, and the decisions worth taking care over are usually the ones with a real cost either way.
Half an hour with your own data usually saves reading three of these. The guides will still be here afterwards.