The goal is for anyone to be able to visit a team roadmap and understand how to gather information from that roadmap. “Anyone” could be Chad, Landon, Mike, Dan, an EM or an engineer from another team, a business analyst, a product manager, or any other JHA Digital employee.
Information must be sufficiently consistent between each team’s roadmap. That is, for example, the definition and usage of an “epic” to one team must mean the same thing to another team. Issue topology (Initiative -> Epic -> Stories, Tasks, etc) must be used consistently by each team. Each team must adopt the same definition and understanding of issue types and critical fields (Start Date, Due Date, Status, etc.).
The information expected to be available on a team roadmap are:
- Each initiative a team is expected to have a part in, where the initiative is either beginning in the future or in progress, or that has a team epic that is in progress.
- All team epics for a particular initiative.
- Initiatives and related epics must be in a hierarchical view.
- The start date for each team epic.
- The due date for each team epic.
- The status of each team epic, which can be interpreted as or condensed to Not Started, In Progress or Done.
Issue types, fields and usage are described in the Intro to Jira document. Teams should already be adhering to the practices outlined in that document.
Teams should try to maintain a single roadmap, rather than keeping one for planning, one for tasks, etc. Instead, filters can be used to increase or decrease the resolution of the roadmap. After teams have had time to dial in their processes around a single roadmap, we will have a stretch goal of implementing a larger engineering view that pulls in roadmaps from all groups.
Internally, teams can have as many roadmaps as they want, but there should be one (that has a standardized name across all teams) that is the default.