A Sprint connects a short cycle to a meaningful goal
In Scrum, a Sprint is a fixed period of no more than a month during which value is created and the necessary events take place. It is more than a deadline for a random collection of tasks.
An illustrative team is improving class booking. It could fill a cycle with colour changes, a new report and a colleague's unrelated request. Or it could choose a goal: help visitors understand the different formats before submitting a request. The second approach makes it easier to explain why some tasks are included and others must wait.
People also use “sprint” informally for other short working periods. This article concerns Scrum and product-work planning. If your team uses its own weekly cycle, keep that distinction in terminology clear.
- List
Edit copy, move a button, add a section. The connection is unclear.
- Goal
Make the choice of format clearer; select specific work to support that change.
Three planning questions
The Scrum Guide describes Sprint Planning through questions about the Sprint's value, what can be completed and how the selected work will be done. The goal is developed collaboratively, while Developers plan how to create a result that meets the Definition of Done.
| Question | The team's answer |
|---|---|
| Why this cycle? | Check whether the choice of class format is understandable |
| What will we take on? | Clarify the explanation and make the necessary change to the booking scenario |
| How will we do it? | Prepare content, implement, check and discuss the result |
| What are we leaving out for now? | An unrelated report and cosmetic changes that do not affect the goal |
The last row matters: a goal helps explain deferred work as well as included work. Real commitments cannot simply be ignored, however. If urgent necessary work exists, discuss its effect before promising capacity the team does not have.
How to assess available capacity
Check people's availability, external events and the work required for quality. Holidays or mandatory maintenance mean the calendar duration is not the team's fully available working time. Use your own past experience while retaining uncertainty.
- Availability
Who can actually work, and when?
- Readiness of candidate items
Are the result and constraints clear enough?
- Quality
Is there room for implementation and the necessary checks?
Do not fill the entire period with optimistic estimates just to make the plan look good. Equally, do not assign a universal buffer without understanding the situation. Discuss which unknown conditions matter and how they affect the forecast.
What to do with changes during the cycle
New information is inevitable. The team can refine how it reaches the goal as it learns. Make the effect of a change visible rather than silently adding work on top of the selection. Discuss an external request: does it support the goal, how necessary is it now and what will it displace?
- Name the new fact or request.
- Check its effect on the goal and quality.
- Discuss scope and consequences with the relevant people.
- Update the immediate plan transparently.
- Record the decision so the team does not work from different expectations.
An obsolete goal is a separate situation, not ordinary task reordering. The official guide defines Sprint cancellation and the relevant accountability in Scrum. Do not invent another rule and present it as the standard.
Planning with a specific set of candidate items
The illustrative booking service has four candidates: explain class formats, fix the loss of a selected time, build an administrator report and update decorative icons. The Sprint Goal is for a visitor to choose a format and complete a booking. The first two items support it; the report and icons stay outside the scope for now.
First, the team checks whether it can complete the entire scenario. An explanation is unhelpful without working booking, while the booking fix needs checks on the relevant devices. The plan therefore includes integration, checking and correcting findings, as well as writing copy and code. Loading the team “100% with development” would leave those activities invisible.
Next, account for actual availability: holidays, support for the existing product and known meetings. Estimates in relative units do not remove calendar constraints. If two parallel items need the same specialist, discuss sequencing or reducing scope. A sum of optimistic estimates is not a guarantee.
The result is a plan for reaching the goal, with a clear first step. It is detailed enough to start but can be refined as new information appears. Another team's capacity template does not determine how much this team must take on; the decision rests on its capabilities and evidence.
Unfinished work and urgent requests
On day three, an urgent request arrives for a new report. First, establish whether it is a genuine commitment, the consequences of delaying it and whether it supports the Sprint Goal. If necessary, the team and Product Owner discuss changing the scope. You cannot treat the original plan as untouchable while quietly expanding it.
If some work is unfinished at the end of the cycle, show its actual state. Do not mark a card complete to improve a percentage. Discuss the remaining work, its value and what comes next; carrying it into another Sprint needs fresh consideration. New information may have made the original solution unnecessary.
Review why the forecast was wrong: a hidden dependency, an unavailable specialist, an item that was too large or a late check. Choose one change for the next cycle, such as checking an external integration before detailed implementation rather than merely promising to “estimate better”.
Assess the Sprint through its goal and usable result. Counts of closed tasks without context cannot compare teams: the same work can be split into five cards or twenty.
Choose the next step that can be checked
Start with one task: “Prepare a check of how clearly the formats are explained.” Record the expected output in the description: a scenario, observation questions and criteria for discussing the improvement's result. You do not need to transfer the entire article into the app; save what you will need while doing the work.
Prepare the check before implementation ends. Keep it alongside the other actions so the result discussion rests on facts.
- Create a task with a specific action in its title.
- Add the completion conditions and necessary context to the description.
- Choose a day and check whether the work fits alongside your other commitments.
Signing up for Sinqly is free. You can also work through the article's example in an ordinary document; the app helps you return to the actions you chose.
Finish the cycle with useful knowledge
Inspect the usable result and new information about the product. Then discuss the way of working separately: where waiting occurred, what helped and which experiment to try next. Product feedback and process improvement are connected, but they answer different questions.
Do not assess the cycle only through the proportion of items closed. A team can complete many small tasks without advancing the goal. It can also discover an important constraint that changes the next choice. Keep the goal, actual result and next decision connected.
A good Sprint leaves a result and a basis for the next choice. A calendar boundary is useful alongside transparent work and inspection.
More questions to clarify
Must a Sprint last two weeks?
No. In Scrum, the duration is fixed and does not exceed a month. Choose a rhythm that fits the conditions and opportunities for feedback.
Can tasks be added during a Sprint?
Changes need transparent discussion of their effect on the goal, scope and quality. The team's capacity is not unlimited.
What should we do with unfinished work?
Check its actual state and the reasons, then make a fresh decision about what happens next. Automatic carry-over does not replace a choice.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Scrum Guide: Scrum rules and events
- Scrum Guide: Sprint
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
Story points: estimating work without converting it into hours
Relative estimation with story points: choose a reference task, discuss differing estimates and explore uncertainty. Why points should not become hours or individual performance targets.
Project backlog: keep an idea list that helps you choose work
How to collect ideas, clarify tasks and choose the next work without an endless list of promises. An example backlog for a small product and rules for reviewing it.
Scrum or Kanban: choose an approach that fits your team
Compare Scrum and Kanban through the nature of your work, incoming requests and need for feedback. Two illustrative scenarios and questions to ask before choosing.