Sprint Board App Design

Northwind Sprint Board

This official OpenDesign example presents the Northwind Growth Squad during Sprint 38, Day 6 of 10. The desktop workspace places the board at the center and keeps a Sprint Pulse sidebar visible on the right, so operational work and summary context can be read together.

The top bar establishes scope before the cards begin: “NORTHWIND / GROWTH SQUAD” is paired with “Sprint 38 · Day 6 of 10.” Search tickets, Filter, and New appear at the opposite edge. This ordering supports a quick transition from identifying the current sprint to locating or adding work, while reserving the main area for task comparison.

A filter strip separates controls from task content. Member initials, the Active sprint, Bug, Feature, and Research labels, plus Group · Status and Sort · Priority controls make the board’s sample organization explicit. The tradeoff is density: many control choices remain visible, but the user can understand the board’s intended grouping without opening another screen.

Workload and Blocker Review

The design is suited to a team reviewing what is waiting, moving, being reviewed, or complete. Cards use a repeated structure: a colored work-type band, a task title, an owner avatar, a point estimate, and an issue ID such as NW-241. That repetition lets readers compare unlike work without losing the ticket’s identity.

The sample data also demonstrates different kinds of work in one queue. “Add empty-state illustration to onboarding step 2” sits beside “Interview 5 new Enterprise admins about 2FA enforcement,” while “CSV export drops emoji from project names” makes a defect visible as a separate class. The type bands distinguish Feature, Design, Research, Chore, and Bug, but the shared card anatomy keeps those categories comparable.

This arrangement favors scanning over detailed ticket discussion. A team can see that the research item carries 5 pts and that the CSV export issue carries 1 pt, but the board does not explain estimation rules or acceptance criteria. Those details would need a deeper task view in a production application; they are outside the visible design.

From Board to Sprint Pulse

The workspace reads from left to right across Backlog, In progress, In review, and Done. Their displayed badges are 5, 4, 3, and 6. The first three match their visible card counts, but Done contains only four cards despite its badge of 6. The left-to-right sequence still distinguishes workflow stages; the sample count mismatch should be resolved before using the board as operational data.

Progress bars appear only on several In progress cards, including TOTP enrollment UI in member settings, Recovery codes, Fix focus-trap regression in command bar, and 2FA challenge step. Their presence visually separates active progress from cards that are simply assigned a state. Because the visual does not define what the bar measures, it should be read as an illustrative progress cue rather than a verified completion metric.

The sidebar changes the reading scale from tickets to a sample sprint summary. It shows Completed 22 of 38 pts and lists Devon Park at 9 pts, Mira Reddy and Priya Banerjee at 5 pts each, and Caleb Renner at 3 pts. Those contributor values total 22, but the four visible Done cards total only 11 points. The source does not explain that difference, so the sidebar and board should not be treated as a reconciled performance report.

The final sidebar block makes a relationship between status and dependency explicit. “1 ticket needs unblock” identifies NW-205, described as waiting on a copy review from Brand, with “Mention @Sasha or move it back to backlog” as visible follow-up guidance. Keeping this beside the board makes the dependency harder to miss, although the sidebar occupies persistent space that could otherwise widen the task area.

Visible Design Boundary

This artifact is a design-only desktop-app example with illustrative names, figures, task contents, and claims. The captures establish the visible composition, labels, color coding, ordering, and sample state. They do not establish a connected production service, persistent storage, working search, filtering, ticket creation, or real-time updates.

For an adaptation, preserve the specific relationship between the four workflow columns and the Sprint Pulse sidebar. A useful implementation would need an explicit definition for point totals, progress bars, blocker actions, and state changes before presenting them as operational data. The source shows the interface contract clearly enough to prototype those states, but not enough to claim that the controls already perform them.