Lucyboard use case

Plan the sprint around the goal, not around ticket scrolling.

Put the sprint goal, capacity, must/maybe/out-of-scope items and risks in one view. Then move the final scope to your project tool.

Lucyboard sprint planning board with goal, capacity, scope and risks.

Short answer

Online sprint planning should agree on goal, capacity, scope and risks before the ticket list takes over.

Lucyboard is useful for the planning conversation before backlog execution: input, candidates, dependencies and final handoff.

board helps before tickets, not instead of them · capacity and risks stay visible · output is sprint goal and backlog handoff

goal, capacity and dependencies · must, maybe and out of sprint · visible next to the plan · handoff to backlog

Planning agenda

60-90 minute sprint planning: goal, capacity, scope, risks

Use the board to align on the plan before the backlog takes over execution.

  1. Input

    Write the goal, capacity, holidays and dependencies.

  2. Scope candidates

    Sort work into must, maybe and out of sprint.

  3. Risks and decisions

    Add unknowns and missing decisions beside the work they affect.

  4. Output

    Confirm the sprint goal and move selected work to your project tool.

Planning agenda

60-90 minute online sprint planning agenda

Planning works better when the team understands the goal and limits before reading the backlog.

Input

  • sprint goal
  • capacity and availability
  • dependencies

Scope

  • must and maybe candidates
  • risks
  • out-of-sprint items

Output

  • sprint goal sentence
  • PO and team decisions
  • tasks moved to project tool

Who it's for

Best for planning conversations before the execution tool takes over

  • scrum teams planning a sprint remotely
  • product owners who need scope tradeoffs visible
  • teams that want risks and dependencies in the same view
  • facilitators trying to avoid planning only by ticket order

Ticket order is not a sprint goal

A sprint planning meeting can easily become a backlog reading session. The team discusses items before agreeing on capacity, risk and the real goal.

A board helps keep the big questions visible: what outcome matters, what capacity is real and what is consciously outside the sprint.

What to agree before the backlog

Goal. Write the sprint outcome before discussing individual tickets.

Capacity. Show availability and constraints so the scope does not inflate.

Risks. Name dependencies and missing decisions before calling the sprint planned.

A simple 60-90 minute agenda

Start with goal and capacity. Sort candidate work into must, maybe and out of sprint. Add risks and missing decisions next to the work they affect.

Finish with a sprint goal and a clear handoff to Jira, Linear or ClickUp. The board should explain the plan, not run the sprint.

Sprint planning board with goal, capacity, scope and risks

Keep risks visible

Risks usually appear during planning, then vanish when tickets get created. Put them next to scope decisions while the team is still choosing.

This makes later tradeoffs less surprising because everyone can see what was known during the planning conversation.

Lucyboard vs the usual stack

Lucyboard or planning only in the backlog

The backlog executes the work. The board helps the team agree what the sprint is actually about.

Sprint goal

Lucyboard — visible from the start

Usually elsewhere - easy to bury between tickets

Capacity

Lucyboard — seen next to scope

Usually elsewhere - often discussed verbally and forgotten

Scope tradeoffs

Lucyboard — must, maybe and out-of-sprint side by side

Usually elsewhere - a list hides tradeoffs

Execution

Lucyboard — handoff only

Usually elsewhere - project tools should own workflow

Questions

Questions about online sprint planning

These answers show where a board helps before the backlog and where it should hand off.

Does Lucyboard replace the sprint backlog?

No. Use Lucyboard to plan and explain the sprint. Move execution into your project tool.

What should be on the board at the start?

Sprint goal, capacity, dependencies and anything that can limit scope.

What should stay after planning?

The goal, chosen scope, key risks and why those decisions were made.

Does this work outside Scrum?

Yes. Any team planning a short cycle around a goal can use the same structure.

Next

Related use cases

Sprint planning pairs with agile workshop and retro pages because together they cover the team conversation cycle.

Lucyboard Education ->

Plan around the goal, not just the ticket list

Go through input, scope, risks and output. Then move execution into your project tool.

Online sprint planning | Goal, scope and risks on Lucyboard