A colourful list of blocks just comprehensible enough for all the stakeholders to realise you are needed after all.
I haven't really come across a standardised version on this. Use a dedicated tool, or simply a spreadsheet, with 3 axis: time, team & features. Depending on the depth one of those 3 will be vertical. In the example file, this happens to be the features.
First, define your unit. A team can be a single unit, or be made out of multiple execution units, depending on the nature of the developers and the job.
Second, define the weight of your block unit (full sprint, half sprint, ...), and break down features to the level where you feel confident to assign sprints to it. The rule of thumb is straight forward. If you are at a level where you need less then half a sprint on average, you've gone too far. If none of your features take less then 2 sprints per unit, break down more. Obviously, for these assessments you need to have full ownership of the features. Prepare that first, don't feel shy to get better informed by your tech lead later.
Don't forget to buffer: get to know your stakeholders. One's assessment you have to double, other's you'll typically have to cut of a third. Whatever pattern, always add some time to the critical features, and plan some nice-to-have units around, which can be easily killed in sprint.
An average roadmap can span up to 12 months without being the exception. Keep improving your assessment on nearby units, and put on the rough brush for horizon features.
| Role | entry |
|---|---|
| Product Owner | https://github.com/Cloudoki/scrum-team-toolbelt/tree/master/roles/product-owner.md |
| Sponsor | https://github.com/Cloudoki/scrum-team-toolbelt/tree/master/roles/sponsor.md |
Roadmap tooling reviews welcome.
This reference is open for improvements. Help us build a better story. Read how to contribute here.