This page contains information about the roadmap for DevOps but may also include a description of actual issues and related developments. This service roadmap should not be confused with a software or technology development roadmap. Individual service offerings, elements, components, developments or teams can have their own roadmaps which should be referenced here and mutually aligned; most of them are normally not visible to users. Instead of using the provided Roadmap Planner macro and the table of activities, the team may give a link or attach a presentation (for example, one based on this multi-service/offering PLM Roadmap Template) or a spreadsheet or content in any other format and keep it up to date using an external (project management) application or tool such as JIRA or Trello. However, it should be accessible to anyone who is able to see this page. RESPONSIBLE: Content is defined and maintained by the DevOps team. |
Overview Roadmap
The visual overview roadmap is a communication tool used to set the expectations of what planned service changes are and what they will deliver in terms of a high-level strategic plan.
It is better not to name bars with release or milestone codes or names of individual features – the release numbers are not very informative, while a release typically includes works by several teams (i.e. bars in several lanes) or several features, some of which may be postponed. While the visual roadmap provides a general overview of the planned work, the associated table of actions is used to deliver additional details and needed descriptions. |
Actions
The table of actions serves to support the visual roadmap by providing additional information. It can be used as a high-level backlog, to do list or list of main changes, but the individual items need to be understandable by laymen. Each item is a phase of work, action or activity or feature group (marked by a bar), or one of bar or marker-related tasks or features. The rows either correspond to the bars in the visual roadmap or represent the individual actions or features associated with bars or markers. Using this table for individual assignments or minor changes would make it unmanageable, uninformative or overly technical in a long run; the detailed tasks and assignment should be managed with a dedicated project management tracker. If rows need to be grouped by theme or lane(s) (team, stream or offering), it is better to split them into several tables then to merge adjacent cells (to group releases or multi-part actions), as this prohibits sorting.
COMMITTED – Will be in this release. PLANNED – Is planned to be in this release but additional work is required before it could be Committed. POTENTIAL – Early stages of planning, more work is to be done before the item is moved it to Planned.
NOT STARTED (eduTEAMS ON HOLD?) (Core Team NOT NECESSARY, TBD?), Deferred, Waiting (on Something/Someone)? FINISHED (Core Team DONE, COMPLETE?), Completed, Resolved? IN PROGRESS (eduTEAMS ONGOING?) CANCELLED
|
(Simple version)
Action | Description | Priority | Status | Due date | Assigned to | Comment |
---|---|---|---|---|---|---|
|
(More detailed variant)
Release | Commitment | Action/Feature (choose one to indicate what is in rows) | Description | Priority | Status | Due date | Assigned to | Comment | Created on | Closed on |
---|---|---|---|---|---|---|---|---|---|---|
|