Scrum — to infinity and beyond

Scrum is like a box of chocolates…chocolate is always worth a try! (unless you’re a dog)

Why should I care about…Scrum?

  • stay productive and creative = happy team members 😊
  • deliver a product that end users want = happy customers 😊
  • minimize a waste of time and money = happy business owners 😊

Why would anyone create Scrum?

  1. business people => create a DETAILED requirements specification
  2. architects => create a DETAILED system architecture with all kinds of fancy diagrams
  3. developers => can finally start coding
  4. testers => get the finished code and can start testing the system
  5. devOps => a long, long time has passed and the system can be deployed
  6. now make sure it still works the next day
Waterfall model

The main flaw with the waterfall model is that it doesn’t take into account any uncertainty. Everything is planned down to the last detail at the beginning, and it is assumed that the plan is correct. However, the initial plan is always incorrect and it’s complicated to change it later in the process. That’s why Scrum comes to save the day…or years of wasted effort and

The Scrum recipe

Scrum Sprint

From a pile of papers to a visible product value

As a <Who is this task being done for?>,
I want <What do we want done in the first place?>
so that <Why does this user want this thing?>.

Why is the key part because the team may know a better, easier and faster way to achieve the very same goal.

Each user story has to have 3–7 acceptance criteria — a list of conditions that say when the story is done. If you end up with less than 3, you need to specify them better. If a story has more than 7 criteria, break the story to multiple smaller stories. You can see a few examples on

User stories are written by a person that knows how to translate the requirements into true, meaningful value, a.k.a a Product Owner. A Product Owner can ask the development team to participate in writing user stories.

Then user stories are estimated in relative units, a.k.a story points, by the development team. The most common estimating technique is Planning Poker.

Planning poker

Let’s roll!

Sprint Planning meeting is the first step in each Sprint. The team looks at the list of user stories, a.k.a Backlog, and decides how many they can accomplish this Sprint. The user stories should be estimated before the Sprint Planning, otherwise there can be questions that can’t be answered in the meeting.

Pulling stories from the Backlog should get easier after 3–4 Sprints, when you have a steady velocity. Velocity in Scrum means: how many points the team can finish in a Sprint. If your velocity is 50 points, you should pull stories worth 50 points or slightly more.

Sprint Planning

Daily bread à la Scrum

In Daily Stand-up each team member should answer 3 questions:

1. What did you do yesterday to help the team finish the Sprint?

2. What will you do today to help the team finish the Sprint?

3. What obstacles are getting in your way?

Did we get it right?

The Sprint Review can show if you’re heading in the right direction. It can also tell you what the end users value most — you might have to reprioritize the Backlog and/or create new user stories.

Good, better, best

What is the little improvement that can be done right away that will make things better?

You should leave the Sprint Retrospective with 1–3 improvement actions for the next Sprint. In the next Retrospective you can then assess the action points and see if you managed the improvements.

The world never sleeps

Every Sprint you can schedule a meeting — the Backlog Refinement — where you review the Backlog. You can discuss new user stories, remove irrelevant stories, re-estimate and re-prioritize the stories.

Extra: why is it called Scrum?

The term comes from the game of rugby, and it refers to the way a team works together to move the ball down the field. Careful alignment, unity of purpose, and clarity of goal come together. It’s the perfect metaphor for what I want teams to do.