Sprint Goal: One Sentence, Not a Ticket List

From the field: 8 October and the wrong item

Sprint 9 ran from 29 September to 10 October. Six people, nine items. Four of them belonged to the same piece of work: a flow that lets a new customer make the first deposit in the app. The bank callback integration, the deposit screen, the error messages, and the guidance step after the first deposit. The other five had nothing to do with each other: a font fix in the statement PDF, a filter in the admin panel, sorting on the watchlist, a log clean-up and a library upgrade.

On Monday 13 October, marketing was going to start a campaign: “Open an account, trade with zero commission after your first deposit.” The PO knew this. The list did not.

On 8 October, the picture was this. Mehmet had lost a day and a half to a statement bug in production. The bank callback integration had also taken two days longer than we estimated. We were about four person-days short. The discussion went in three directions. Everyone defended their own item. Someone said “I have done half of it” twice. In the end, the easiest arithmetic won: drop the item that is big enough to close the gap alone. That item was the guidance step after sign-up, three person-days. It was the step that told a new customer “now make a deposit” and took them to the deposit screen. The PO agreed too. The campaign date was in the PO’s mind, but in that moment nobody connected it to the list.

The sprint closed with seven of nine items done. We even got applause in the review. In the first three days of the campaign, before the missing step went live, 1,240 new accounts were opened. Only 310 of them made the first deposit in the app, which is 25%. The call centre got 380 calls asking “where do I send the money?” The flow was there, but nobody could find it.

I had written the goal. The sprint goal field in Jira was mandatory, and after planning someone had to type something. I typed “Complete the Sprint 9 scope.” That sentence did not give the decision to anyone. So the decision went to the loudest voice.

What the goal is for: owning the scope decision

The Scrum Guide defines the sprint goal as the single objective of the sprint. Right after that, it adds the key sentence. If the work turns out different than expected, the developers work with the PO to renegotiate the scope of the sprint backlog without changing the goal. So the goal is fixed and the scope moves. When the goal is the list itself, nothing is left to move. The list breaks every sprint, and the mood in the room decides which part breaks.

Later I looked back at who makes that decision when there is no goal. There are four candidates. On 8 October, the first three were at the table at the same time:

The fourth row looks the most harmless, but it does not solve the problem either. If the decision always comes from the PO, the team waits every time something does not fit. The job of the goal sentence is to make this decision once, at the start of the sprint, and put it in everyone’s pocket.

What a good goal sentence looks like

I use four conditions. If one is missing, we rewrite the sentence:

• One sentence. If it contains “and”, there are probably two goals. Two goals make you choose again when work does not fit.
• It describes an outcome, not work. Not “build this screen”, but “this person can do this”.
• You can check it with yes or no. At the end of the sprint, “did we meet it?” should be a matter of looking, not arguing.
• It covers the core of the list, not all of it. Items that do not serve the goal can still be in the sprint. We call them flexible.

p95 means the time within which 95% of requests finish. Put your sentence through one test. I call it the “8 October test”: on day eight of the sprint, two items do not fit. Reading this sentence, can you say which one to drop in one minute? If you cannot, the sentence is not a goal.

The goal is the core of the list, not all of it

Since Sprint 10, we put a letter next to every item in planning: G (serves the goal) or F (flexible). Flexible items are also in order. When work does not fit, they go from the bottom up.

Our rule for the ratio: goal items take about 60% of the capacity we can commit to. With the calculation in the Sprint Planning post, if we commit to 33 person-days, about 20 go to the goal and 13 to flexible items. Why not 100%? If the goal is the whole list, there is nothing flexible to drop, and you are back on 8 October. Why not 30%? Then the goal is a small corner of the sprint, and nobody takes it seriously.

GOAL: A new customer can make the first deposit in the app,
      without calling the call centre.
CHECK: in-app first deposit rate for campaign accounts
       at least 50% within two weeks

G1  Guidance after sign-up to first deposit   3 person-days
G2  Clear error message on bank callback       4
G3  Copy IBAN button on deposit screen         2
G4  "First deposit" card at end of sign-up     5
G5  Deposit status screen for call centre      6
                                     goal = 20
F1  Watchlist sorting                          3
F2  Statement PDF font fix                     2
F3  Admin panel filter                         4
F4  Library upgrade                            4
                                 flexible = 13
                                    total = 33

Who writes the goal? In the past it was me, after planning, to fill the Jira field. Now the PO comes to planning with a proposal: “This sprint I want this, because there is a campaign on 13 October.” We talk about the sentence before the items. While the team picks items, they make the sentence narrower or wider. The Guide says the same thing: the goal is the work of the whole Scrum team. A goal written by one person stays that person’s goal.

G1 did not wait for the weekly release because of the campaign; it went live on day three of Sprint 10 in an extra release. In the second week of the campaign, the in-app first deposit rate was 57%. The check line was met. The sprint closed with eight of nine items done; the one left was F4.

When something does not fit mid-sprint

Now the order of the decision is clear from the start:

1. Flexible items go first, from the bottom up. No debate; we agreed the order in planning.
2. If that is not enough, make a goal item thinner. What is the thinnest version that still meets the goal? “The status screen shows three steps” instead of six.
3. If the goal itself no longer makes sense, this is not a scope decision. It is the PO’s decision to cancel the sprint. I described the order for that in the Being Agile post, so I will not repeat it here.

The place of the decision changed too. Not 40 minutes of six people’s time. Ten minutes right after the daily, with the PO and the two or three people doing the work.

Sprint 11 was the first real test. It ran from 27 October to 7 November. We had removed the 29 October public holiday from the capacity at the start. The goal: “A customer with a withdrawal request can see which step it is at in the app.” On 3 November, Ayşe went on two days of sick leave. On the same day, a notification bug in production took one person-day. We were about three person-days short. On the morning of 4 November, right after the daily, the decision took six minutes. F4 (the library upgrade, again) and F3 (a new column in an admin report) came out. The sprint again closed with seven of nine done. All five goal items were done.

Coming back to the goal in the daily

In the Daily Standup post, I wrote the one question of the meeting: are we on track to reach the sprint goal? The question is right, but on 8 October there was no goal to ask about. Once we had a goal sentence, we added three small things to the daily:

• The sentence is at the top of the board. When someone shares the screen, it is the first line people see. Nobody has to memorise it, but everyone reads it once every morning.
• When walking the board right to left, G items come first. If a G item and an F item are in the same column, we talk about the G item first.
• The last 30 seconds: confidence in the goal, from 1 to 5. Everyone shows it with their fingers. If someone shows 3 or less, the topic goes to the parking lot: ten minutes with the PO.

In the Sprint 11 daily on 3 November, two people showed 2. The decision came the next morning, because the size of the production bug became clear around noon that day. In Sprint 9, we learned the same bad news at 16:40 on day eight. In Sprint 11, we learned it on the morning of day six.

How it breaks

Writing a goal sentence is easy. Keeping it alive is hard. These are the ways I have seen it break, in our team and in teams I have talked to:

The last one is the most dangerous. When the goal starts to look out of reach, it is tempting to soften the sentence: “the infrastructure is ready” instead of “the customer can see it”. If you do that, the goal is met every sprint and says nothing. If you missed the goal, say so. A missed goal is information. A goal that changes quietly is noise.

What to watch

• Goal success rate. In the last six sprints, how many times did we say “yes”? If it is always yes, the goals are too easy. If it is less than half, the capacity calculation is broken.
• Time to make the did-not-fit decision. For us it went from 40 minutes to 6. If it gets long again, the goal sentence has become unclear again.
• Postponed flexible items. The library upgrade was dropped in two sprints in a row. A flexible item dropped for the third time either becomes a goal item in the next sprint or goes back to the backlog. It cannot stay flexible forever.

Checklist

Conclusion

On 8 October we argued for 40 minutes, because the answer was not written anywhere. The campaign date was in the PO’s head, the items were in Jira, and no sentence connected the two. The result was 380 calls and a rate stuck at 25%.

A sprint goal is not a motivation slogan. It is a way to make, in advance, the decision nobody wants to argue about on a tired Wednesday afternoon in the middle of the sprint. You write the sentence in planning so you do not have to write the decision at 16:40.