Sprint Planning

Balance scope, capacity, priority, and carryover while giving the team a realistic sprint commitment. The screen connects Backlog and Sprint so product teams can find the “Start sprint” action while checking planned points and capacity.

Use this reference when you need to design this workflow inside an existing product. The example includes practical records such as Checkout retry logic and Workspace invite flow, rather than an empty visual shell.

Sprint Planning

Template facts

Screen

Board

Primary action

Start sprint

Pattern

Board

State

Default, loading, empty, error, permission, success

Design system

Adaptable product UI theme

What this screen helps users do

Product teams need a clear “Start sprint” action without losing sight of planned points, capacity and the affected records. Keep the decision and its outcome clear before moving to the next task.

Key elements

  • Primary action: Start sprint is clearly available where the task happens.
  • Main view: Backlog keeps the starting point obvious.
  • Connected view: Sprint supplies nearby context.
  • Metric: Planned points is visible with a meaningful value.
  • Another signal: Capacity helps people judge what to do next.
  • Representative record: Checkout retry logic makes the example specific.
  • Second record: Workspace invite flow shows the pattern works beyond one item.

States worth designing

  • No items in a stage; show what people can do instead of leaving a blank panel.
  • Loading backlog without changing the layout unexpectedly.
  • Move blocked by access rules; explain the problem and preserve work.
  • Permission denied for sprint; clarify who can continue.
  • Success after choosing Start sprint; confirm the result and the next step.
  • Network or data refresh failure; offer a retry without losing context.

Where this screen sits in the flow

Backlog → Sprint → Start sprint → Review outcome

Patterns used

Board, Backlog, Sprint, Capacity, accessible states, contextual actions

Why these choices work

Use meaningful stages and clear ownership. Keep the next action visible on each card; confirm high-impact moves.

In this design, people should be able to compare Checkout retry logic with Workspace invite flow. Make planned points clear, then use capacity to explain whether the next step needs attention.

Before handing this to a designer or engineer, check keyboard focus, error copy, permissions and what happens after they choose the “Start sprint” action. The happy path alone is not enough.

Related UI examples: Project Timeline, Product Roadmap, Task Board.

Start from this in Figr

Design a sprint planning screen for our existing software product. Use our real design-system tokens, components and product language. Show Backlog and Sprint, include believable records such as Checkout retry logic, and make start sprint easy to find. Map loading, empty, failure, permission and success states before you create editable high-fidelity screens.

Open Figr