Checklists are good. They make us remember things. Especially when it is things we do over and over again, when it is easy to forget one step just because we’ve done it so many times already. I mean, we’re just human. If we look around, many operations where risk is high often use checklists. Like pilots. They are fanatic when it comes to following the pre-flight checklist, because if they miss anything, even the smallest thing, it could end in disaster. Lives are at stake. But few airplanes go down because of pilots skipping this step. I think it’s safe to say that checklists work. They evidently increase the quality of things we do.

Now, imagine if we had a checklist when we develop software? How much good would that do for us? Now, you read the headline, so it’s not a surprise when I say that we actually have one. It is the Scrum process.

Scrum is a process with a lot of well-defined steps that we’re expected to do and that has clear expectations of the outcome. That is in its essence a checklist. Just like the pre-start checklist the airline pilot goes through to avoid any catastrophic failures during flight, Scrum ensure that all the necessary information is created so we can produce the code that the user needs.

The neat thing with Scrum as a checklist is, it’s built into our daily work, we just do it, we never forget to pull out the manual and look at the paper. The team has consensus on the steps and the collective makes sure that no steps are forgotten.

Let’s break it down and see what it looks like.

The neat thing with Scrum as a checklist is, it’s built into our daily work, we just do it, we never forget to pull out the manual and look at the paper. The team has consensus on the steps and the collective makes sure that no steps are forgotten.

Let’s break it down and see what it looks like.

The user story

It starts with the user story. “As a <stakeholder> I want to <do this> to <solve that problem>”.

First, to deliver software that works, we have to define all the stakeholders of a system. You know, processes or people that are affected by it, that is expecting an outcome. The user story requires us add this.

If you want to delve into the stakeholder part of the user story, for instance why it’s bad to only have the single stakeholder called “user”, you can read about this in this article.

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

Second, we have to write down what the problem is that we’re trying to solve. I mean, there’s no point in doing it if we don’t have anything we need done. So, what is the problem we’re solving with the user story? What is the expected outcome? That’s the <solve the problem> part.

And the third, we add how we want to solve the problem. The <do this> part of the story.

If we format the story as a checklist, it might be clearer what I mean.

What the checklist reminds us of	The Scrum process
Identify the stakeholders.	Use the “As a <stakeholder> in the user story.
Identify the problem we are solving.	Use the “to <solve that problem> in the user story.
Describe how we intend to solve the problem.	Use the “I want to do <this>” part in the user story.

The backlog

Prioritize it

The backlog is all about planning the work. The stakeholders tells us what is most important to them so we can prioritize. For instance, the customer stakeholders tells us what they want done first, the developers (also stakeholders) informs us of what we have to do from a technical standpoint, and as a third example the law dictates what we have to do to avoid breaking it. All this tells us what we need to sort the user stories.

Refine it

Now, a user story with only a headline does not have enough information to solve it. First, we need to decide on the architecture. If we don’t know how we are going to realize the story, we can’t code it. And this decision is better made when we can focus on the bigger picture, instead of doing it at the same time as we write code, which tends to use the first solution that pops up in our minds because we have other things to think of. Also, if the whole team is part of the design, we pull in the same direction and the code will be much more cohesive than if everybody makes their own design decisions.

Read more about the details of the refinement

Estimate it

We also need this information so we can estimate the size of the work ahead. Not the time it takes to develop it, it’s different for each developer, so it’s impossible to say; but the number of things we have to do and how big they are. No matter who does it, it’s the same code we have to write. It is a pretty big difference between writing a comma separated file and creating a database with normalized tables, indexes, and relations.

Read more about story points and how they work
Read more about how you do the estimate

Now we have enough information that the next step in the process has something to work with.

What the checklist reminds us of	The Scrum process
Make sure no stories is forgotten.	Add them to the backlog.
Make sure the stories that is most important is done first.	Sort the backlog.
Create the design and architecture for each story.	Design the architecture, choose technology, and add it to the story.
Make sure the design is finished and everybody understands it.	Review the story in the refinement until everyone understands it.
Let the stakeholders know how big a user story is and what to expect.Add information so sprint planning can avoid overtime.	Estimate the size of the story using storypoints.

Sprint planning

Adding stories to the sprint

The next step in the checklist is the part where we move from thinking about what to do, to more about how to do it. First of all, we recognize that we can’t do everything at once. We have to focus. And to do that, we need time to focus. You know the story points we estimated in the previous steps? Let’s put them to work. Assuming we already have done a few sprints with story points, we have the current velocity of the team.

That means that you know, by experience, roughly how many points we can manage. It’s not a guess, it’s actual facts. We actually have done that many story points before. It stands to reason that we will do that this sprint too. There is no point in pulling in more storypoints than this, that is, if we don’t plan to work overtime.

Making code form the design

Now it’s time to think of how to code the story.

Compare with this. The user story is to serve our guests a delicious meal. The architecture that we decide on is the same as choosing what we’re going to cook. Is it Coq au vin, Fish and Chips or maybe Roast beef?

Before we can start cooking, we have to decide what ingredients we need, how to cook it, what spices we want and so on.

This is what we do when we create the tasks. We identify each component we need to build.

Guestimate time left until we’re finished

When we are done describing the task, we have a pretty good idea of how long it will take to complete it. We add that as “time left” in the story card. Since we’re on such a detailed level, we can estimate in hours.

And just like story points, we will need the time estimate in the following part of the process.

What the checklist reminds us of	The Scrum process
Only plan to do what is possible to finish within the sprint.	Look at the velocity from previous sprints. The sum of the stories we drag into the sprint should never exceed that level.
Decide how we are going to solve the design in technical terms.	Create tasks that describes what technical solution we choose to realize the design.
Set up a warning system so we can get an early warning when there are problems.	Put a time estimate on each task.

The sprint

Standup

As you surely know, if you’ve heard anything about Scrum at all, we always start the day with a daily standup. Everyone answers these three questions.

1. What am I finished with? Or am I still working on it?
2. What will I do today? What new task will I tackle?
3. Do I have any problems that have and impact on the team, or simply that I can’t solve by myself?

We do this to make sure we act as a team and not as a bunch of headless chickens. This is the time to coordinate. Where do we stand in the project, what do we have left? And the third question is all about solving the unknowns that we discover about the story now that we are in the middle of coding, things that we didn’t find during refinement and sprint planning. Whenever we scratch the surface of a task, we will find new things that has to be addressed on a team level.

Maintaining the sprint backlog

Then we have the sprint backlog. It is a tool that will give us a good overview of the progress. With no, or at least small effort, we can see what is done, what is being worked on and what is left. It helps the team to know what someone is working on and what is up for grabs. No risk of two people working on the same thing.

Related article: The sprint is actually a set of goals

Burndown chart, the canary in the mine

And finally. The burndown chart is a way to automate the process of showing the health of the sprint. We get the computer to show us if there are any problems, and in a way that is crystal clear. One glance at the chart and we see if we deviate from the expected, and theoretical, line.

Read more about the burndown chart
Read about what not to do with a burndown chart

Now, a problem is probably something that we need to do, but we weren’t aware of when we did the estimate. It is impossible to find everything when we do breakdown of the user story. Quite frankly, we’re not even supposed to, because that would mean we more or less would have done all the work before we start the sprint. We just have to expect them. But we want to expose them as soon as they pop up, so we can solve them right away, instead of discovering at the end, when everybody thinks we’re finished, that we aren’t.

What the checklist reminds us of	The Scrum process
Clear communication on what is done means that we all know where we are in the process.	Answer the first standup question: What have I done yesterday, what am I finished with?
Collaborate with each other, like don’t start working on the same thing.	Answer the second standup question: Am I starting with anything new, or do I continue with my current task?Assign tasks to you and mark them as done when they are ready for delivery. Now everybody can see the progress with just a quick glance.
Use the collective knowledge and experience in the team to solve problems rather than wasting time trying to solve it on my own.	Answer the third standup question: Do I have any problems?
Become aware of that we have a problem as quick as possible.	Look at the burndown chart, at least each standup.Update the time left on the task you’re working on, so the burndown chart is up to date.

After sprint

We’re done! We’ve delivered! Now let’s get feedback!

A big part of Scrum is about getting feedback as soon as possible so we can adjust and correct without wasting time on doing the wrong thing. Like, refinement where we make sure we understand the user story before we do anything with it. Or the burndown chart, that shows us when we have problems before the sprint is done.

But the biggest feedback activities in Scrum happens after we have delivered. There are two activities I’m talking about, the sprint review and the retrospective.

Sprint review

The first is all about making sure that we did what the stakeholders wanted us to do or explain why we did things in a certain way. This will undoubtedly lead to that the stakeholders start thinking about how this can be improved, they start seeing new possibilities. And this leads to new user stories, which is great! Now, we’ve found out things that neither we nor the stakeholders knew they wanted at the beginning, but absolutely would have requested after we were done, and we would have to waste time changing things. Now, we do it right from the beginning.

Read more about the sprint review (demo)
Read about why it is important to fail fast, or in other words, the importance of frequent reviews

Retrospective

The second is not so different, except we look inwards instead. We ask ourselves if the way we did things is the best way to do it, or if we think we can change the process to become better. Yes, I’m talking about the retrospective. This is when we get a chance to improve our work situation.

What the checklist reminds us of	The Scrum process
Are the stakeholders satisfied? Can we catch new and improved ideas from the stakeholder?	The sprint review. We show the work and talk about what we’ve done and what we are going to do.
Is the team satisfied?	The retrospective. We have time set of exclusively for improving the way we do things.

Conclusion

Checklists are good. They help us stay on track. Like the white lines on the road, they guide and steer us in the right direction. We often notice that when we step outside and don’t follow the checklist, we end up regretting it. Like trying to drive outside the lines of the road in the grassy roadside, we will pretty soon notice that the road is bumpy and slow, and the risk of crashing into a rock or a tree is pretty big. So, embrace checklists. They make things easier.

Oh, and if you want to read all my articles on Scrum, you find them here:
https://developerkingdom.se/scrum/ — Cheers!