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.

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
On this page
Jump straight to the section that best matches what you need.
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.
Input
Write the goal, capacity, holidays and dependencies.
Scope candidates
Sort work into must, maybe and out of sprint.
Risks and decisions
Add unknowns and missing decisions beside the work they affect.
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.

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.
Plan around the goal, not just the ticket list
Go through input, scope, risks and output. Then move execution into your project tool.

