2. The roles and the rhythm of scrum
Agile tells you where you want to go. Scrum tells you how to start on Monday morning. It is by far the most widely used interpretation of agile thinking, and it consists of a handful of agreements that you can explain in an afternoon. Three roles, three artefacts, five events. Anyone who knows those eleven concepts knows scrum; anyone who actually sticks to them has a team that runs.
After this chapter:
- You know what scrum is, where it comes from and why it is called a framework and not a method.
- You know the three pillars: transparency, inspection and adaptation.
- Do you know the three roles, the three artefacts and the five events, and can you tell them apart.
- You can explain what a Definition of Done is and why a team needs one.
- You can recognise the three pitfalls that reveal scrum-on-paper.
A framework, not a method
Scrum is a lightweight framework with which teams develop complex products in short, repeating cycles. The word comes from rugby: a scrum is the moment when the whole team pushes forward together to move the ball. Jeff Sutherland and Ken Schwaber set out the approach in the first Scrum Guide in 1995.
The difference between a framework and a method matters, including in the exam. Scrum does not prescribe what you build, which technique you use or how you test. It gives you a rhythm, a division of roles and a few recurring moments. You fill in the content yourself, together with your team and your client.
Scrum rests on three pillars that you will see in every sprint. Transparency: everything that affects the work is visible to everyone involved in it, so no shadow lists. Inspection: you regularly look at what you have made and how things are going, not once a quarter but every day and every sprint. Adaptation: what you see during that inspection is what you use to adjust course. A deviation is not a problem, it is information. Together they form the empirical process that scrum rests on: you learn by doing.
The three roles
A scrum team has three roles. No more, no fewer.
The Product Owner is the voice of the customer and the business within the team. He or she decides what gets built and in which order, manages the Product Backlog and makes sure the team knows why something is valuable. One person, not a committee, otherwise you lose decisiveness. A Product Owner chooses what is valuable and leaves the how to the team. And a Product Owner without a mandate is a go-between who slows down every sprint.
The Scrum Master is not a project manager and not a boss, but the team's coach. The Scrum Master makes sure scrum is applied properly, clears obstacles that are holding the team back and protects the team from outside disruptions. Does not hand out tasks and does not set deadlines.
The Development Team does the work. Usually three to nine people, multidisciplinary: all the skills needed to deliver a working piece of product are present within the team. No separate testers outside it, no designers joining later. The team is self-organising, which means precisely that it decides for itself how the work gets done. The what comes from the Product Owner via the backlog.
The three artefacts
Artefacts are the tangible carriers of information that the team works with. They make visible what needs to happen, what is happening now and what has been delivered.
The Product Backlog is the complete, prioritised list of everything that needs to be done to the product at some point: functionality, improvements, bug fixes, technical tasks. What matters most is at the top. The list is never finished and changes as soon as you learn more. The Product Owner is the owner.
The Sprint Backlog is the part of the Product Backlog that the team takes on in the current sprint, plus a plan for delivering those items. This is the Development Team's own working document. It stays up to date during the sprint: items are split, re-estimated or updated, as long as the sprint goal remains intact.
The Increment is the working piece of product that is finished at the end of the sprint. Genuinely working, tested and potentially usable. Not a half-finished product that is nearly ready. Every sprint delivers at least one Increment.
The five events
Scrum has five fixed events. The first is the container within which the other four take place.
The Sprint itself lasts one to four weeks and always has the same length within a team; two weeks is the most common. Sprint Planning opens the sprint: the Product Owner explains the priorities, the Development Team determines how much work is feasible, and at the end there is a sprint goal and a Sprint Backlog. The Daily Stand-up lasts a maximum of fifteen minutes, every working day at the same time: what did I do yesterday, what am I going to do today, what am I running into. Flagging issues, not solving them. In the Sprint Review at the end of the sprint, the team shows what has been built; stakeholders give feedback and that feedback goes back to the Product Backlog. Not a PowerPoint but a working session. And in the Sprint Retrospective, immediately after the Review, the team looks at itself: what went well, what could be better, which concrete action do we take into the next sprint.
This is how the cycle runs: during Sprint Planning the team takes the top items from the Product Backlog. These form the Sprint Backlog, which remains the team's own for the whole sprint. At the end there is an Increment that meets the Definition of Done. In the Review it receives feedback, and that feedback ends up back in the Product Backlog. Then it starts all over again.
The Definition of Done
The Definition of Done is a shared agreement within the team about when work is truly finished. Think of: the code has been tested, the documentation has been updated, a colleague has reviewed it, and it is on the acceptance environment. It applies to everything the team delivers, not per item. Put it up where everyone can see it, or pin it at the top of your digital board. Discussions about "is this finished or not?" then disappear of their own accord, and the Increment means the same thing to everyone.
At an insurance company, a team of seven people works on a claims portal. The Definition of Done was not written down anywhere, and the same discussion arose at every Review: the Product Owner considered three of the seven items unfinished, the team thought otherwise. In the Retrospective of sprint 6 they wrote one down together, with four points: tested by someone other than the builder, error messages in Dutch, works on mobile, and the manual has been updated. In sprint 7 the team took on four items fewer, because it suddenly became clear how much work came after the building. From sprint 9 onwards the velocity was back at its old level, but the team was now delivering items that the Product Owner accepted without discussion.
Three pitfalls
Theory is one thing, getting a scrum team to work is another. Three pitfalls come up everywhere.
An unclear sprint goal. The team works on separate items without a shared story. Ask a team member what this sprint is about and you get a list of tickets. A sprint goal should explain in a single sentence what makes the sprint valuable.
The Scrum Master as project manager. As soon as the Scrum Master hands out tasks, sets deadlines or takes the status in the stand-up, the team is no longer self-organising. The Scrum Master removes impediments and safeguards the process, nothing more.
Stretching the sprint. "Just one more week and we'll make it." That way you lose the entire rhythm as well as the meaning of your velocity. A sprint is a fixed timebox. Whatever is not finished goes back to the Product Backlog and may return next sprint.
The most common mistake is using the Daily Stand-up as a status meeting for the manager. Test it like this: is everyone talking to the same person, or are team members talking to each other? In the first case it has become a reporting session, and then you might as well scrap it.
A development team at a wholesaler notices during the Retrospective that the Daily Stand-ups are running on to half an hour. Two people discuss the same technical problem every morning while the other five stand and wait. The action for the next sprint: one team member takes on the role of timekeeper and cuts off any discussion lasting longer than two minutes with "park it, we'll pick it up after the stand-up". Two sprints later the stand-up is consistently down to twelve minutes, with an average of two people staying on for another ten minutes. That is exactly the intention: the conversation did not disappear, but the other five are no longer standing there for it.
Multiple teams
Scrum was designed for a single team. If several teams are working on the same product, you will come across frameworks such as SAFe, LeSS and Nexus. These build on the scrum basics and add coordination between teams. For the Foundation exam it is enough to know that they exist and what they are for; the underlying principles remain the same.
Pick a team you are involved with, even if they do not use scrum.
- Can you write down in one sentence what the team will deliver over the next two weeks?
- Who fulfils the role of Product Owner, and who that of Scrum Master? Are those roles genuinely assigned, or is someone doing them on the side?
- Which of the five events are held consistently and which are regularly skipped? The Retrospective is the first to go.
- Is there a Definition of Done? Can everyone recite it?
Discuss your answers with a colleague from the same team. The chances are that your views differ, and that is exactly where the value lies.
Summary
- Scrum is a framework, not a method: it provides rhythm, roles and moments, not the content.
- The three pillars are transparency, inspection and adaptation.
- The three roles: Product Owner (what and in which order), Scrum Master (coach and obstacles), Development Team (three to nine people, self-organising).
- The three artefacts: Product Backlog (everything that needs doing at some point), Sprint Backlog (what needs doing now, drawn up by the team itself) and Increment (what is finished).
- The five events: the Sprint as container, Sprint Planning, a Daily Stand-up of no more than fifteen minutes, Sprint Review and Sprint Retrospective.
- The Definition of Done is the shared agreement about when work is finished, and it applies to everything the team delivers.
- Three pitfalls: no clear sprint goal, a Scrum Master who directs, and a sprint that gets stretched.
Halfway through the sprint, a manager asks the Development Team to take on one small extra request. What should the Scrum Master do?
Who owns the Sprint Backlog?
At the end of the sprint an item has been built but not yet tested, while testing is part of the Definition of Done. What happens to that item?