Is a sprint goal still useful when agents build?
Stefan-Iulian Tesoi · · 6 min read
More useful than before, because it is the only part of the sprint left that can say no. When agents clear the selected work in days, the sprint backlog stops being a constraint and becomes a queue. A sprint goal is the test for what gets added mid-sprint, what gets dropped, and whether the week achieved anything beyond a count of closed items.
What is a sprint goal for once agents build?
It names the week's one outcome, so every scope decision has something to be tested against. The 2020 Scrum Guide calls it "the single objective for the Sprint", one that "provides flexibility in terms of the exact work needed to achieve it." The items are a forecast of the route. The goal is the destination.
The guide pairs each artifact with a commitment: the product goal for the product backlog, this one for the sprint backlog, the Definition of Done for the increment. It also gives the goal a veto: "No changes are made that would endanger the Sprint Goal."
Human teams rarely needed that veto, because a full fortnight already made new requests wait. With agents, once the selected items are in review by Wednesday, capacity says yes to everything, and the goal is the only thing left that says no.
Sprint planning with agents becomes a readiness check, which answers the guide's second planning topic: what can be done. The goal answers the first, why this sprint is valuable. Forty ready items give no reason to build any particular ten.
Why is a full sprint backlog not a goal?
Because a list says what will be built, not what will be different afterwards, so it cannot rank anything that was not on it.
Take a team of five running three coding agents. Fourteen ready items go into the sprint on Monday. By Wednesday twelve are in review and six more have become ready. The list cannot say which of the six should join, or whether the week has done its job. Twelve of fourteen is 86 percent: a good number if the two outstanding items are cosmetic, a meaningless one if the release needed them.
| Mid-sprint question | A list of items | A goal |
|---|---|---|
| A new item is ready. Does it join? | Yes, and with agents there is always room | Only if it serves the outcome |
| What gets dropped? | The lowest priority | Whatever the outcome does not need |
| Was the week a success? | A percentage closed | Yes or no, at the sprint review |
| An item is the wrong approach | The sprint is behind | Another route to the same outcome |
A list of items says what will be built. A goal says what will be different on Friday, and only the second can turn away an item that is ready.
How do you write a goal the work can be checked against?
Write one sentence naming a change a user or stakeholder could observe, and agree on Monday how it will be checked. Most advice on how to write a sprint goal comes down to refusing the shapes that look like goals and are really lists. A usable one passes five tests:
- It names an outcome. "Finish the billing epic" is a list with a name.
- It has a check: a demonstration, a command or a number someone can observe at the review.
- More than one set of items could reach it. Otherwise it is the list again.
- It excludes something ready. If nothing stays out because of it, it decided nothing.
- It serves the product goal, which the guide calls "the long-term objective for the Scrum Team".
A coding agent is judged item by item against acceptance criteria, and it will report its own item finished. The goal is judged across accepted work, never on the agents saying they are done. In Laimonade a coding agent can carry an item to In Review and no further: a person accepts it, or Laimon, the product owner agent, closes it with the closure stamped as its own.
Five weekly goals, before and after
These sprint goal examples are hypothetical. Each "before" describes activity; each "after" describes a result.
| Before | After | Checked at the review by |
|---|---|---|
| Finish the billing epic | An annual customer can switch to monthly billing unaided | Switching a test account on staging |
| Improve performance | Order history loads in under two seconds for the largest account | A timed load on that account |
| Close fifteen items | Support can answer "where is my refund" from the admin panel | Someone from support, live |
| Tech-debt sprint | Nothing calls the legacy login endpoint | Zero requests in 48 hours of logs |
| Onboarding improvements | A new workspace connects a repository without a support ticket | A fresh signup, walked through |
Each "after" can be reached by items other than Monday's, so a wrong item can be swapped out without the week failing.
What happens when the goal is met by Wednesday?
The sprint continues, and the remaining days go to whatever makes next week's goal reachable. The Scrum Guide does not cover a goal met early. Its sprints are fixed in length, and the one reason it gives for cancelling a sprint is that "the Sprint Goal becomes obsolete", which an achieved goal is not.
With the days that are left:
- Confirm it. Run Monday's check on accepted work, not on items sitting in review.
- Pull work toward the product goal, agreed with the product owner. The guide lets scope "be clarified and renegotiated with the Product Owner as more is learned". It does not invite a second goal mid-sprint.
- Specify next week. The nearly-ready items decide what the next goal can be, and people's time is now the scarce input.
- Treat a habit as a sizing signal. Met by Wednesday every week, the goal is too small for the cadence: grow it, or shorten the sprint.
In Laimonade the outcome layer above items is the milestone, an outcome with a target date, so a weekly goal reads naturally as the step one sprint takes toward a milestone. How items move through that week is set out in the sprint workflow.
Frequently asked questions
Should every item in the sprint serve the goal?
No. Most weeks carry bug fixes and maintenance that serve no particular outcome, and forcing them under the goal makes it vague. The goal settles contested scope: when something has to be added or dropped mid-sprint, the items that serve it win. If fewer than half of the week's items serve it, though, it is a label rather than a goal.
Can a sprint have more than one goal?
Not in Scrum. The 2020 Scrum Guide calls it "the single objective for the Sprint", and a second would not help: two goals cannot settle a conflict between themselves halfway through the week. When two outcomes both matter, make one the goal and treat the other as ordinary scope, which is the first thing to give way.
Who writes the sprint goal?
The whole Scrum Team, at sprint planning. The product owner proposes how the sprint could increase the product's value, the team agrees the wording, and the Developers commit to it. A coding agent has no part in it: it is checked item by item against acceptance criteria, while the goal is the people's test for which items get in.