How I Scrum

A friend asked if I had anything written down regarding “what I do” as a ScrumMaster & coach. Here is what I’ve quickly written as a result.

It’s a recipe, I suppose, so please note: inexperienced cooks like myself are prone to follow a recipe exactly, measuring with precision and still producing something never quite as good as the original. But I have noticed that a skilled cook will add their own flair and flavor to a recipe. In so deviating from the original, they often improve upon it, suiting it to their diners’ tastes and eventually making it their own.


Get started: build a product backlog.

Every item is a feature that can be shipped on its own and adds real, demonstrable value.

  • Value can come from anywhere: user delight, shortened future development time, guaranteed quality, etc. Just know what that value is.
  • Each individual item could be the only thing you do in a sprint and it would still result in a potentially shippable product increment.
  • You don’t need many details. A description of the feature is sufficient at this stage.
  • Work with your Product Owner and build this list of features until you have what you imagine is 2 to 3 months of work. This might take a little time, so dedicate yourself to the task. Don’t move forward without it.

Refine the product backlog on Thursday.

Understand the important stuff. (1.5 hours.)

  • Meet with the entire Scrum team (ScrumMaster, Product Owner, developers).
  • Put the items in priority order. The whole team discusses what should be highest priority. The Product Owner has the absolute final say on priority.
  • If developers think something should be high priority, they sell it to the Product Owner, explaining the value. Try to convince them, accept it if you can’t. There’s always next sprint.
  • Developers estimate items in order. That estimate is anything but a unit of time. Use fibonacci numbers, a 1–10 scale, a 5-star scale, a thumbs-up or -down metric. Anything but time.
  • If developers need more information in order to estimate, they gather that info in this meeting. Read code, ask questions, draw diagrams, create documentation in this meeting.
  • Sometimes refining the backlog means nothing but estimating. Sometimes it means fleshing out a single item for an hour and half. Don’t worry about it. Take your time. Relax.

Plan your first sprint on Friday.

Decide what you will do. (1.5 hours.)

  • Build a Scrum board. It looks like this:
Did you notice there’s no “Checking” or “QA” column?
  • Developers decide which item(s) to pop off the top of the backlog. At least the top-most item must be done. Write this item’s name on a Post-It and put that in the “Items” column.
  • This is the first sprint. It must succeed for team morale. Purposefully agree to do very little work to guarantee success. Often this means just one backlog item.
  • Agree that “done” means “merged into a stable branch (preferably master) and ready to ship at any time (preferably immediately).” This, of course, includes full QA.
  • For each backlog item, developers list the steps they must take to get it to the “done” state. They write them down on Post-Its and put them on a board in “To Do” next to the corresponding item.
  • Typical tasks for an item: writing QA feature tests (scripted & automated if possible), executing feature tests, various coding tasks, code review, branch merging.
  • Estimate tasks if the team wants to. Or just count every task as a “1.”
  • Create a burn-down chart:
Y-axis is task total. X is days of the sprint. Draw an “ideal” line from your task total to Friday, representing the progress you must make to be finished by Friday morning’s daily scrum meeting.

Monday morning have your first Daily Scrum. Continue every morning for two weeks.

It’s a discussion, not a roll-call or status update. (15 minutes.)

  • Everybody stands up and looks at the board.
  • People share with each other what they did yesterday, what they’ll do today, and if they have or perceive any impediments to finishing all the work on time.
  • Start off asking each person these three questions. Gradually stop asking, prompting people to speak for themselves. Aim to eventually have a short, casual group discussion that addresses these questions.
  • Move Post-its around accordingly. Create new Post-its as you discover new tasks, such as bugs discovered in testing.
  • Write down impediments people have on a whiteboard and move on.
  • End the meeting by updating the burn-down in front of everyone. If it shows you’re behind schedule, write this down on the whiteboard with the other impediments.
  • The Daily Scrum is over. If problems were discovered, facilitate discussion to create a plan right then and there for how you will solve the problems discovered.

Refine the backlog again every Tuesday and Thursday.

Casual continued discussion about product backlog items, changing priorities, and estimation. (1 hour.)

  • Create documentation on whiteboards, papers, whatever is convenient. Take pictures.
  • If someone values creating more comprehensive documentation, put it in the backlog.

Friday morning, tasks are finished. Friday is lost to meetings. First: Sprint Review.

Developers show stakeholders what they’ve done. (45 minutes.)

  • Product owner can invite literally anyone they want. Co-workers, end-users, the CEO.
  • Developers show off a live example of what they’ve done, whatever it is.
  • Questions, answers, feedback.

Next: Sprint Retrospective immediately after that.

Developers, Product Owner, and ScrumMaster inspect and adapt. (45 minutes.)

  • Only the PO, Devs, and SM attend. Bring pens and Post-Its.
  • Draw on the whiteboard three columns: Went Well| Did Not Go Well | Improvements
  • 5 minutes of silent writing on Post-Its anything that comes to mind that went well this time or did not.
  • Everyone puts their notes on the board.
  • Open discussion about the good stuff. Recognize what works.
  • Open discussion about the bad stuff. Brutal honesty. Find the problems. Discuss solution ideas for every problem and write it down on Post-It in the third column.
  • Finally, the team free-style prioritizes the Post-Its in the third column.
  • Team decides what to do next time to improve.

Lunch.

Enjoy.

Plan your next sprint.

Nice trick, do it again. (1.5 hours.)

  • How many points did you do last sprint? This time, do more. Always improve. Always find a way to speed up.
  • This time, include your improvement from the Retrospective. Put it on the board as a backlog item and track your progress on it. Yes, really. This is how you will continue to improve.
  • Roughly every third sprint, try to do an amount of work no one believes you can do. Go for it. Dive in. This team needs to be thrown out of the nest...

Have an emergency.

Discover you’re not going to complete the sprint. Then, follow these steps:

  1. Brainstorm as a development team: can we do something different? Something crazy that will let us accomplish all our work? Exhaust all options. If that fails:
  2. Consider getting help from outside the team. Is there an expert with free time? Is there simple work we can easily outsource? If that fails:
  3. Call the Product Owner. Ask if you can trim the sprint scope by removing lowest priority items. If that fails (the PO insists it must all be done):
  4. Abort the sprint. You know you can’t do it. Go ahead and fail early. Regroup and replan. Communicate the cost to management of the Product Owner’s decision. (This probably won’t happen. Faced with the choice to cancel all progress or decrease scope, the PO’s decision is pretty easy.)

Rinse and repeat.

Anticipate and note team weaknesses. Quietly steer them toward their greater potential.

A few obvious ones:

  • Expect roles to arise quickly. At first this playing-to-strengths will be useful for productivity. Eventually, team members must be goaded into doing each other’s tasks. Annoyingly, constantly suggest that coders write tests; that QA learn to code. iOS devs learn Android, server-side devs learn HTML. You must create a cross-functional team.
  • Expect “no blockers” to become punctuation, the taken-for-granted end of a status update. This is a lie. The dev really means “I can handle my problems.” Encourage even the most minor blockers to be reported anyway. “I have blocker X and will solve it by doing Y.” This open communication yields too many benefits to enumerate here.
  • Expect team members to want to work alone on individual backlog items, leading to a sprint where everything is in progress and nothing finished early. This is not teamwork. Direct the developers toward becoming a dev team that finishes the highest priority backlog items first, the next second, and so on. When someone says “Today I’ll work on this task at the bottom of the board,” question whether they can work on the QA task on the higher-priority item higher on the board.

I’ll write more later on the art of being a ScrumMaster. Hopefully this is enough info for now. Special thanks to Jim Coplien and Jeff Sutherland whom I have to thank for my Scrum training.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.