Roadmap and timelines

The roadmap is where time stops being a date field and starts being a shape. An initiative with a start and a target reads as a bar of the right length, in the right place on the calendar, next to the work it depends on. Dragging the bar changes the dates. Dragging from one end of the bar resizes the duration. Hovering an arrow shows which initiative is waiting on which. A timeline you can read at a glance is also a timeline you can edit at a glance, which is the part most products do not get right.

Every roadmap in Disco Parrot is rendered through one shared timeline composition. The per-project roadmap and the cross-project portfolio view sit on top of the same primitive, with the same drag behavior, the same dependency model, and the same five-level zoom from a year-at-a-glance down to a day.

Five zoom levels, one timeline

You spend most of your time in the middle zooms (month and quarter), but the timeline supports five steps from day to year and switches between them without re-rendering the data.

The pixel density per day shifts with the zoom, so a one-week bar at the day level renders as a long bar and a one-week bar at the year level renders as a tick. Zooming in and out keeps the same record under your cursor; the math anchors on what you were looking at rather than dropping you at the start of the visible range.

Your workflow can set a default zoom for the initiative roadmap. The choice survives between sessions, so a team that always reads its roadmap at the quarter level lands there on every open without anyone clicking through to it.

Drag a bar to move it, drag an edge to resize it

Picking up a bar and moving it left or right reschedules the work. The drag snaps to whole days, the start and target shift together to keep the duration constant, and a drop at the original position does not write a phantom change. Multi-select a few initiatives and drag them as a group; a small stacked preview at the cursor confirms the count so a multi-select never feels like a single-select gone wrong.

Resizing happens at the edges. Grab the left edge to change the start, the right edge to change the target. The bar grows and shrinks live as you drag. If the resize would push one end past the other, the platform holds it at a one-day minimum rather than letting the bar invert.

Milestones (the diamond-shaped marker for a point-in-time event) skip the resize handles entirely. They are a date, not a range, so resizing them does not mean anything.

A long drag across several months auto-scrolls the timeline when your cursor gets close to the edge, and the math follows the scroll, so the bar lands where your cursor actually was at the moment you let go.

Dependencies as part of the plan

Initiatives carry a list of prerequisites; the timeline draws those as arrows from the prerequisite to the dependent, with orthogonal paths that route around other bars instead of cutting through them. The arrows are not decoration. The graph is queryable, the rollups respect it, and the timeline uses it to keep your plan honest.

Creating a dependency

Each bar has four small handles, two on each side, that initiate a connection when you grab them. Drag from the right of one bar to the left of another and you have created the dependency the moment you drop. Drag from the left side of one bar onto another and the direction reverses. The line follows your cursor as a draft until you commit.

Removing one

Hover an arrow that is already there and a small remove control appears at the midpoint of the line. One click and the dependency is gone, the arrow disappears, the audit log records the removal. There is no confirm; the move is small enough to undo by drawing the arrow again.

Cycles caught at the drag

The interesting part is what happens when the dependency you are about to create would form a cycle. The timeline runs a depth-first walk on the prerequisite graph from the source bar to the target before it accepts the drop. If the path you are drawing would close a loop, the draft arrow turns red, the drop indicator shifts to a warning state, and the platform refuses the move at the UI layer.

The server has the same check as a backstop, but you do not get to a 422 response because the timeline never sent the request. A cycle in a dependency graph is a planning error that costs hours to debug after the fact; we catch it at the drag.

Sub-tasks under their parents

Sub-tasks on the roadmap are a hierarchy under an initiative bar. Each child can have its own start, target, and dependencies; together they roll up onto the parent's row in a way that depends on whether the parent is collapsed or expanded.

When the parent is expanded

The children render below the parent, stacked and indented to show the relationship. Each child drags and resizes on its own. Dependencies between children render the same as any other arrow, and a dependency between a child and an unrelated initiative draws across the indent.

When the parent is collapsed

The children disappear from view and the parent's bar takes on a striped pattern, spanning the full range of its children's start and target dates. The bar's title gets a count of how many descendants are inside the collapsed branch.

A chevron on the parent toggles between the two states. Small bars hide the chevron but you can still click the body of the bar to expand or collapse.

The rollup is computed, not stored. Adding a child whose target sits past the current parent end extends the parent bar; deleting that child contracts it. The number you read off the parent always reflects the work that is actually planned.

Unscheduled work on the side

Not every initiative has dates yet. The unscheduled drawer on the right edge of the timeline lists the initiatives that are missing a start or a target, drawn as cards rather than bars. The drawer resizes to give you more or less room. Each card carries the title, the owner, and the status, the same way a card on the Kanban board does.

Dragging an unscheduled card onto the timeline schedules it. The drop position sets the start date, the target lands a week out by default, and the card disappears from the drawer the moment the drop lands. If the write fails for any reason, the card returns to the drawer and the bar disappears from the timeline.

Hover for the rest of the story

The bar itself shows the title, the status, and a small avatar for the owner. Hovering it opens a popover with the rest of the fields you wanted to see without clicking through. Owner, project, plan count, progress percentage, open bug count, custom dates: the fields in the popover are configured the same way card fields are, through the workflow. The same catalog drives the grid columns and the Kanban card; the roadmap hover reads from it too. Edit the workflow's roadmap hover field list and every popover updates with the change.

Click a bar (or right-click for a new tab) and you are looking at the full initiative detail through Quick View, with the roadmap still mounted behind it. Close the modal and you are back where you were, with the same zoom and the same scroll position.

The portfolio view across projects

Some questions are not "what is on this project's roadmap" but "what is in flight across the portfolio." The cross-project timeline answers the second one. It uses the same primitive as the per-project roadmap, with one lane per project that has scheduled initiatives, and the bars rendered read-only at a fixed quarter zoom for a clean overview.

Clicking a bar in the cross-project view opens that initiative through Quick View the same way the per-project roadmap does. Drag and resize are off here because the view is for reading the picture; the edits happen on the per-project roadmap.

What entities show on the roadmap

The roadmap renders initiatives today. Plans and bugs do not show as their own bars; they roll up onto the initiative they belong to through the count fields in the hover popover. Sprints and goals have their own timeline surfaces in the product, but they are not on the initiative roadmap.

The choice keeps the roadmap readable. A roadmap that draws every plan and bug as its own bar quickly becomes a wall of bars that means nothing; a roadmap of initiatives with rolled-up counts and progress on each one is a picture a person can actually navigate.