When to open the Board, the WBS, or the Timeline

Every project in Velo shows up in three shapes. The Board is where a card moves from Doing to Done. The WBS (work breakdown structure) is where the project gets decomposed into deliverables and sub-deliverables before anyone touches a ticket. The Timeline is what we show the CFO on Thursday when she asks whether the migration will land before Q3 close.

We built all three because a project has three audiences: the person doing the work, the person shaping the work, and the person funding the work. They need different resolutions of the same truth.

The Board is for the next 72 hours

Open the Board when you want to know what is moving today. It answers: which cards are in progress, which are blocked, who owns them, and what will ship by Friday. Columns default to Backlog, Ready, Doing, Review, Done. We use the same keyboard shortcuts as Linear so nobody on the team has to retrain their fingers when they switch tools.

Rules of thumb for when the Board is the right lens:

• Daily standup at 9:15
• Triaging a Slack ping from support about a production bug
• Deciding whether to pull in a stretch card during the sprint
• Checking WIP limits before merging another design review

The Board hides context on purpose. You will not see when the epic started, how it maps to Q3 goals, or whether the effort estimate has drifted from the original budget. That absence is the feature. During execution, more context slows you down.

The WBS is for the first two weeks and the ugly middle

The WBS is where a project is born. Before we open a Board we sit with the product lead and break the initiative into deliverables, then those into sub-deliverables, then those into work packages. A migration project we ran last quarter had 4 top-level deliverables, 19 sub-deliverables, and 63 work packages by the time we stopped decomposing. Each work package eventually became one or two cards on the Board.

The biggest mistake we see, in our own team and in every team we onboard, is this: people build a WBS in week one, move everything to the Board, and then never open the WBS again for the rest of the project.

That is where projects die quietly. The Board tells you what is in flight. It does not tell you what you promised, what you dropped, what got scoped out, or what nobody has picked up because it sat in a sub-deliverable that never got carded. Six weeks into a project, the Board looks healthy and the actual deliverable is missing a third of its scope.

We now run a WBS review every second Wednesday. Fifteen minutes, one question per branch of the tree: is this deliverable still on the plan, or did it fall off the Board without a decision? About one time in five we find a work package that should be a card and is not. About one time in ten we find a card doing work that is not in the WBS at all, which is a scope conversation waiting to happen.

The Timeline is for people who do not touch the work

The Timeline is a rolled-up Gantt with milestones, phase bands, and dependencies. It is what we send to the exec sponsor, the finance partner, and the customer stakeholder on a Tuesday-morning update email. We do not use it to plan work; we use it to communicate about work.

A few things the Timeline does well:

1. Shows the critical path when a dependency slips.
2. Shows milestones against calendar dates, not sprint numbers.
3. Shows phase overlap, so a stakeholder can see that Discovery and Design were meant to overlap by two weeks.
4. Exports cleanly into the steering committee deck.

If your PM lives in the Timeline, something is off. The Timeline is a read-only surface for people outside the working team. When we catch ourselves editing the Timeline directly, it is a signal that the WBS underneath is stale.

A working rhythm

Here is the cadence we default to on a new project, and the one we recommend when a team onboards to Velo:

• Week 1: WBS only. No Board. No Timeline. Decompose until every leaf is estimable in a day or two.
• Week 2: Cards get generated from work packages. Board opens. First sprint starts.
• Every sprint: Board is the daily surface. WBS gets a 15-minute review mid-sprint. Timeline gets refreshed once, on the day before the stakeholder update.
• Project close: We close the loop in the WBS, not the Board. A card marked Done is a promise kept only if the parent work package was in the original plan.

Three views, one project, three different questions. The Board asks what is moving this week. The WBS asks what we promised at the start. The Timeline asks what the outside world should expect. Skip any of them and the project drifts in a way that is hard to see until it is expensive to fix.