Our recipe for a well-done Sprint
With the product owner as restauranteur, the development team of cooks is responsible for shaping his exact wishes and giving feedback on what is possible or what could be better. My role as Scrum master is mainly that of a facilitator: I ensure that the team can work well and coach the team and the product owner. There is no comparable role in the kitchen and the comparison with a Sprint is, therefore, not total. For example, we also deliver all the user stories after the Sprint and in a restaurant you bring each course directly to the guest. But in terms of planning, communication and coordination, the kitchen and a Sprint have really quite a lot in common.
Refinement: what can we cook?
Taking the menu list and the ingredients, you first look with the whole development team at the size of a ‘course’. The product owner talks with the team about the user story for as long as it takes to understand how it must look and what needs to go into it. Then per course you ask the team: how long will you take? The time needed and the complexity are indicated in story points. In the beginning you come with a number of sample courses for which everyone knows how much time and story points this will require. Then, on the basis of this, you can make an estimate of the new courses.
In terms of planning, communication and coordination, the kitchen and a Sprint have really quite a lot in common.
Sprint planning: how do you decide on the menu?
After estimating the story points for the separate courses, you can decide on the multi-course menu. What starters, main courses and desserts fit the amount of time you have? When planning the Sprint, you decide as a team: in this amount of time we are going to make that.
Daily stand-up: how far is everyone?
Every day you discuss progress as Scrum team, just like the short work meetings in the kitchen. So: how far is everyone getting along with their courses? Are any courses ready yet? For example, you don’t want the dessert to be ready before the starter. The daily stand-up is an important yardstick for the Scrum master to check how far everyone is and whether the planning deadlines will be hit.
Retrospective: how did it taste?
Once delivered the whole team gets together to discus show the Sprint went. What was achieved and what can be improved on next time? We employ, for instance, the three ‘lanes’ method: Keep, Start and Stop. What do we want to keep, what can we do differently and what should we not do. Everyone has an opportunity to come up with points and with ‘dot voting’ we arrive at a joint choice on two or three items for improvement.
5 tips from the Sprint chef
Take these tips to heart for a well-done Sprint:
1. A product owner is surrounded by stakeholders, each with his own vested interests. What is the most important goal? What user story should be tackled earlier? The product owner listens to his cooks (team members) to find out what is possible and what is not. As restauranteur he must have his own vision; he cannot be the plaything of a single stakeholder. Anyone who has watched Kitchen Nightmares with Gordon Ramsey knows exactly what I mean. In this programme you see restaureurs that hold firm to the dying wish of a deceased parent, the wishes of a silent partner who is never in the kitchen or the ideas of a local supplier.
2. To be able to give good direction to the to-ing and fro-ing of the team, it is important for the product owner to be present on the workfloor two or three days a weeks. With the product owner physically present, the team can quickly ask questions, verify specifieke requirements and switch things if necessary. The rest of the week it is crucial for the product owner also to be available via phone or email.
3. Things go wrong whenever the requirements of a user story are not clear for the team. Like half of the ingredients having been left out or only part of the recipe being clear. The team then thinks: it’s an easy recipe, so we can realise it for one storypoint. But during preparation as the cook is standing in the kitchen he discovers that some ingredients are missing and that he is taking much longer than he should. The development team then has to go back to the product owner and verify the requirements, which may make the course bigger and the meal take longer or one of the courses unable to be finished.
4. Does it seem that a user story won’t be ready before the end of a Sprint? During the stand-up you discuss with the team and with the product owner which measures you can take. This is similar to a recipe that has to be modified during preparation because one of the ingredients is not in stock or because the preparation is taking too long.
5. If a user story has to be modified during the refinement, it is better to establish this immediately. If the product owner writes down the modification only days later, this generates a lack of clarity and thus a delay. In practice, it is the difference between first marinating the meat or putting it straight on the grill.
