Sprint planning, capacity, and scrum — minus the fluff
Practical, no-nonsense guides for the people who run sprints. How to plan one in Jira, how to calculate capacity that actually holds up, what a scrum master really does in the room. Written by the team behind Ekko.
6 guides Updated regularly
Jira sprint planning
02 guides- Why sprint planning is so painful — the 6 biggest pain points (and how to fix each) Sprint planning hurts for six recurring reasons: estimates that miss, chronic overcommitment, hidden dependencies, fragmented tooling and stale capacity spreadsheets, meetings that run long, and capacity that's invisible until it's too late. Survey data backs all six — and almost every one traces to the same root cause: teams plan against guesses instead of their team's real, current capacity. 10 min read
- How to plan a sprint in Jira, step by step To plan a sprint in Jira: open your Scrum board, start a sprint from the backlog, pull in a realistic amount of ready, estimated work, assign owners, sanity-check it against your team's actual capacity, then start the sprint. The whole thing should take 30–60 minutes, not a whole afternoon. 9 min read
Capacity planning
02 guides- How to calculate team capacity for a sprint (and what everyone forgets) Sprint capacity = (working days in the sprint × hours or points per day per person) − public holidays − time off − overhead ("tax" like meetings, on-call, and support). Add it up per person, then plan to about 80% of the total. The part most teams forget is the overhead tax — and it's usually the biggest line. 8 min read
- Story points vs hours for capacity planning: which should you use? Use story points when your team is stable and you want fast, relative estimates that dodge false precision; use hours when you need concrete capacity math, have part-timers or contractors, or report to stakeholders who think in time. Most mature teams estimate in points but sanity-check capacity in hours. Pick one unit and stick to it for a whole sprint. 7 min read