Scrum

On this page, I have collected all the articles I’ve written on Scrum. They are organized top-down, starting with a look at why Scrum works. Then I follow that up with the entire process, through the different stages down to the demo.

The psychology of Scrum, why it works

Scrum – the big motivator

When we read about motivation and what makes an organization effective, we often find that the control over one’s work and time is at the very top. Guess what one of the biggest perks of Scrum is? You’re right. It gives a lot of control to the team to plan and execute their work.

The sprint is actually a set of goals

People with goals always outperform people without them. I think that this is the main reason to begin setting goals. We all work better if we have a goal. That is, goals that we commit to, make a promise to ourselves that we will finish. A goal without this is not a goal, it is just a waste of time. What’s the point if I set a goal for myself and then just ignore it? We have to hold ourselves accountable. An integral part of Scrum is setting goals and holding you accountable to them. We call it “The Sprint”.

Routines reduce friction and gets things done

It is always a good idea to remove as much friction as possible. And with friction I mean the resistance to get things done, to start and to keep doing it. There are many ways to do that, and one of them is to have routines. But what does that have to do with Scrum? Routines are learned behaviour. An order of operations that you don’t have to invent every time. You just know what to do next. This speeds up things, and it consumes less energy. Scrum is actually a set of routines that removes friction.

The Scrum process

Different stages of Scrum

Developing software is a journey. We travel form an idea to delivered code. Scrum helps you break up this process into manageable parts that each focus on one value adding task, instead of trying to manage everything at the same time. Each step adds something new to the project and each step builds on each other. This streamlines the work.

User stories

When is the user story “make it better” finished?

We’ve all been told to do the system safer, better looking, faster, or any other vague requirements. So we do what we think solves the problem. But it wasn’t really what the stakeholder wanted. Can we avoid this by quantifying what better means, by putting numbers on it and measure when we are done? The users probably don’t know what they want. Don’t be satisfied with that. Ask questions and clarify the intent. Then make it measurable so you know when you are finished. And yes, you can quantify everything.

The refinement is not just an hour long meeting every sprint

Before we start coding, we have to understand what we are going to create. By breaking out this into its dedicated time, we can concentrate 100 % on this, not being distracted by code (that’s how we do it). This is an important part of scrum where we really dig into the problem. Not only do we want to know what the stakeholders want, the end result and that we have got all the information we need from hem, we also have to decide on architecture, find out dependencies, consider how to mitigate risks, and so on. There is a lot to dig in to during this meeting. That’s why you should have as many of these meetings as you need. Because this is where you lay the foundation to the code you write. It’s not just about briefly looking at the story and guessing a story point.

Who is this “user” that Scrum keeps talking about?

The “user” is way to generic. Instead, you should be specific. Who, or what, makes the request? By identifying all the stakeholders up front, you stand a much higher chance of making a system that actually works, because then you will find all the requirements they have. The typical user, the one we envision clicking away at our app, has some of the requirements for a complete system, but there are so many other stakeholders that also have needs from the system. Have you ever thought of these as stakeholders? The Law, economy, hackers, climate change, developers, maintenance (both people and systems), sales, CEO and so on.

Story points are NOT equal to estimated time!

In a 100 meter sprint everybody runs 100 meters, but they all end up with individual finish times, because nobody run at the exact same speed. It is the same thing with coding. What we are developing has a certain size. But everybody takes different time to develop it. This is the smart thing with story points. They don’t measure how long something takes to develop, they measure how much code there is to develop. No matter if you are a beginner or a seasoned veteran, reading a record from the database is the same for all. And pair this with the speed of the team, i.e. how many story points in average we can consume, and we can get a pretty good idea of how long time it will take for the team to finish.

Estimating story points, a how-to guide

This is a practical guide to getting started with story points. When you begin with Scrum, story points seem hard to understand. They don’t measure anything exact. So, how do we actually do the estimates?

The sprint

The thing that every company does wrong when they start with Scrum

The burndown chart is a tool for the developers. By showing the amount of work left, we can see if we will be finished in time. And you can see problems as soon as they appear. Just by using graphics. The problem is, when everybody else in the company sees the word “hours”, they automatically default to time spent, not time left. This is two completely different measurements. It’s like saying that we have two kilometres left, and using that to show how long we have travelled so far.

Task estimates and the burn down chart, why and how

This is a practical guide to getting started with task estimates and the burndown chart. The article describes how it works, how you set it up and how you should use it.

After the delivery

What makes the demo actually useful?

The demo, or the sprint review, is a way to communicate, to make sure we are on the right path and to plan the next step. It is there for everybody involved in the project to talk to each other and to make sure that we are moving in the right direction. We will find out new information along the way, how we want to use the tool will change when we try it out and so on. Or for that matter, did I understand your request correct and is this what you want?

What the sprint demo is not, is a one way presentation where we show you what we’ve done so you can approve or not. This is NOT an examination in school. We’re on the same team and we’re working towards the same goal.

Failure is always an option

The notion of “Failure is always an option” is at the heart of any successful endeavour. Because it is when we fail that we learn. Yes, you have heard this a million times. But have you ever thought about what that actually means? And maybe more important, how you can change your ways of working to really leverage it?