Very simple work/release plan diagrams can be help to help plan and track work/scope for some feature. Creating these diagrams is usually done by someone that is responsible for delivering a non-trivial feature.
Qualities:
- These are not formal diagrams , and the simpler the better. That said there is value in keeping to the same uniform format across team members.
- Boxes and lines (no bidirectional arrows, multiplicities, spheres, etc)
- Work "flows" from left to right. i.e. you read it from left to right, and top to bottom with the first scope of work near the top.
- Vertical "swim-lanes" represent units of time - usually a sprint is a good time frame, however you don't need to start with knowing the exact sprint numbers.
- Focus on the big picture capabilities (not on the fine details):
- Start from the whole feature / set scope of work, and break it down. Don't go too far, usually no more than 4-6 boxes in any one sequence.
- Break it down far enough to find work that is dependent on other work (e.g. to accomplish a forgot password feature I must have the ability to send email).
- Look for work that can also be done in parallel, ignore for now whom might work on what or how many people might be available. You can refine the diagram later if need be (though it adds complexity and visual noise).
- Use color to denote varying scope or decision points.
- If the scope is really large, break it up into multiple releases - focus more detail on the immediate release, and very little on releases that are not immediate.
...
- Colors could have helped identify scopes of work (multiple requisition, stock tags, stock on hand aggregates).
- Units of time have sprint numbers next to them, some sequenced work is delivered within the same sprint.
- Diagram evolved as work progressed. While still focused on the bigger picture, the added complexity requires better visual queues to be apparent).
...