3. Filling and prioritising the backlog
A backlog is not the same as a task list. A task list contains everything anyone has ever called out, in the order in which it was called out. A Product Backlog contains the same work, but described from the user's point of view and in order of importance. That difference, from what has been asked for to what it delivers and what has to come first, is the work of this chapter.
After this chapter:
- You can write a user story in the format As, I want, so that.
- You know the three C's and why the card is not the most important part.
- You can test a story against the six INVEST criteria.
- You know what backlog refinement is and when to do it.
- You know the four MoSCoW categories and the 60-20-20 split.
The user story
The most commonly used form for a backlog item is the user story: a short description of a wish from the perspective of the end user. Not a technical specification and not a two-page functional requirement, but a sentence that invites conversation. The classic form is fixed:
As a <role> I want <functionality> so that <value>.
That structure forces you to answer three questions. As says who you are doing this for. I want says what it has to be able to do. So that says what it delivers. That last part in particular is worth its weight in gold. Without clear value, the team doesn't know why something matters and can't make sensible choices when working it out.
A good story for a webshop selling garden furniture: "As a returning customer I want to see my delivery address filled in automatically, so that I can check out faster." The role is clear, the functionality is concrete and the value is obvious. Compare that with "fill address field automatically": then you know what needs to happen, but not for whom and why, and therefore not what happens if it doesn't work out.
The three C's
User stories rest on three pillars, the three C's. The card (Card) is only the memory aid; deliberately, not much fits on it. The real work happens in the conversation (Conversation) between the team, the Product Owner and users. And the confirmation (Confirmation) is in the acceptance criteria: how do you know when the story is done?
You formulate acceptance criteria concretely and testably. Not "the password must be secure", but "the password is at least eight characters long and contains a capital letter and a number". Only then can the team objectively establish whether the story is done, and only then can the Product Owner accept it without discussion. Acceptance criteria are separate from the Definition of Done in chapter 2: the Definition of Done applies to everything the team delivers, the acceptance criteria apply to this one story.
INVEST
Not every sentence in the As-I want-so that format is automatically a good story. The acronym INVEST gives you six criteria to test that.
I for Independent: the story can be built separately from other stories. N for Negotiable: the content is open to discussion and not set in stone. V for Valuable: the story delivers clear value to the user. E for Estimable: the team can estimate how much work it will take. S for Small: the story fits within one sprint, preferably with room to spare. T for Testable: you can objectively establish whether it is done.
In practice, Estimable and Small are the two that usually go wrong, and often at the same time. If the team cannot estimate, the story is too large or too vague. Splitting is then the solution: not into build steps ("first the database, then the screen"), but into smaller pieces that each deliver value in their own right.
Backlog refinement
A backlog that is left untouched for months goes stale. That is why the team schedules a refinement session regularly, often once or twice per sprint. Together with the Product Owner, the team works through the top items on the backlog. Stories are clarified, stories that are too large are split, priorities are adjusted and first estimates are made.
The aim is for the top of the backlog to be sprint-ready at all times. When the next Sprint Planning begins, there are enough clear, estimated and prioritised stories ready. Refinement is not one of the five scrum events, but an ongoing activity; teams usually set aside a fixed hour a week for it.
A team at a health insurer has a story on the backlog: "As a policyholder I want to submit my claims online so that I do not have to send post." At the refinement, half the team estimates it at 8 points and the other half at 40. That difference is the signal: the story is not Estimable, and therefore too large. They split it into three. One: upload and save a photo of a receipt. Two: enter the amount and the date for that receipt. Three: be able to track the status of the claim. All three deliver value in their own right, all three fit into a two-week sprint, and all three get 5 or 8 points in the second estimation round. The first one went into the next sprint, the third is still on the backlog and nobody misses it.
Prioritising with MoSCoW
In chapter 1 you saw why prioritising is not a side issue in agile: time and budget are fixed, so the scope moves with them. Ask a client what has to be included and you get a long list. Ask what is most important and the answer is often: everything. But if everything is equally important, nothing is important, and the team gets spread across too many tasks at once.
MoSCoW is an acronym in which each consonant denotes a category; the o's merely make the word pronounceable. Note the spelling, as that too may come up in the exam.
Must have is what absolutely has to be in this release. If you drop a Must, the delivery has failed. The test: can you deliver the product at all without this functionality? If the answer is no, it is a Must. In a webshop, "customer can check out" is a Must; without that function you do not have a webshop, however fine the product pages may be.
Should have is important but not critical. You do your best to deliver it, but if time is short it can move to a later release. The delivery remains workable without it, even if that feels uncomfortable. "Customer receives an order confirmation by e-mail" is a Should.
Could have is desirable and delivers extra value, but can be dropped painlessly when time runs out. Could haves are your flexible buffer. "Customer can have their order gift-wrapped" is a Could.
Won't have this time is deliberately excluded for this release. Not forgotten, not still to be discussed, but actively taken off. It is precisely by putting things on Won't that you create clarity and prevent scope creep. "Customer can order by voice command" is a Won't for now; perhaps next year.
The 60-20-20 rule
The strength of MoSCoW lies in the distribution. The guideline is 60-20-20: roughly 60 per cent of your effort goes to Must haves, 20 per cent to Should haves and 20 per cent to Could haves. Won't haves take no effort by definition. Stick to this and you have a built-in buffer of 40 per cent. If things go against you, you sacrifice Could first, then possibly Should, and your Must stays standing.
A sprint consisting of 90 per cent Must haves is not an ambitious sprint but a sprint without a buffer. One setback and something gets dropped that should never have been dropped.
Record not only that something is a Must, but also why. If the context changes, you can go back to your reasoning instead of having the discussion all over again. And renegotiate the priorities at every Sprint Planning: what was a Could last month may be a Must this month.
A team of six is working on a new booking module for a travel agency, in two-week sprints and with a velocity of around 30 points. After the prioritisation session, the sprint looks like this. Must: search by destination (8), show availability (5), pay online (5), 18 points in total, which is 60 per cent. Should: filter by price range (5), which is just over 15 per cent. Could: holiday tips per destination (3) and a social media share button (3), 20 per cent in total. Won't have this time: real-time chat with a travel adviser, explicitly deferred to the next release and therefore 0 points. Halfway through the sprint, the payment integration turns out to be heavier than expected: 5 points extra. The team drops the share button and the holiday tips and keeps the four most important stories intact. The sprint ends on time with a working increment, and the marketing department, which had asked for that share button, hears from the Product Owner why it was dropped and when it will come back.
Take a project or a product you are currently working on.
- Write three user stories in the As, I want, so that format. Force yourself to genuinely fill in the so that part.
- Test every story against the six INVEST criteria. Where is the weak spot? Usually with Estimable or Small.
- For each story, formulate two acceptance criteria that you can check objectively.
- Make a list of ten wishes and divide them across Must, Should, Could and Won't have this time. Then count the share of Musts. If you are above 60 per cent, what do you take out?
Summary
- A user story briefly describes who wants something, what and why: "As a <role> I want <functionality> so that <value>".
- The three Cs: Card is the reminder, Conversation is the real work, Confirmation is the acceptance criteria.
- Acceptance criteria are concrete and testable and apply per story; the Definition of Done applies to everything the team delivers.
- INVEST tests a story against Independent, Negotiable, Valuable, Estimable, Small and Testable.
- Backlog refinement keeps the top of the backlog sprint-ready; once or twice per sprint, together with the Product Owner.
- MoSCoW consists of Must have (without this it has failed), Should have (important, can be postponed), Could have (desirable, the buffer) and Won't have this time (deliberately excluded).
- The 60-20-20 split across Must, Should and Could builds in a buffer; Won't takes no effort.
A team estimates the same story at 8 points one time and 40 points the next, and after two rounds still cannot agree. Which INVEST criterion is under the most pressure here?
What does it mean when an item is placed on Won't have this time?
A sprint is 85 per cent filled with Must haves. What is the biggest risk of this?