In the olden days we had a group of people gather and describe every step needed to reach a goal, every function that had to be developed and how long each step would take to develop. A project plan was created. Gantt charts was painstakingly drawn. And when all this was finished, it was handed over to a project manager that made sure that it was executed.

In Scrum we do it a bit differently.

First of all, we don’t plan everything up front. We see this as a massive waste of time, and I will explain why.

We solve each problem one by one. We experiment with it and make sure it is what everyone wants before moving on to the next problem. This is good because we will find a lot that doesn’t work as we originally imagined. We take this information with us into the next step. Now, the thing is that we haven’t spent weeks or months putting together a plan that is incorrect and we now have to change. Or in worst case scenario, have to scrap and rewrite entirely. We only had to revise what we work on now.

But Agile doesn’t mean we just improvise. We still need a plan. We still need to describe the things we are going to develop.

Scrum project management starts on a high level, where we describe the general direction. We declare the problem we want to solve and describe what we want the end result to look like. And because we don’t want to lose too much time when (not if) we have to change the plans, we plan as little as possible that lets us move forward. We only create details when we need them. And for now, we only use broad brush strokes.

But to actually develop anything, we do need details. So to keep the planning as small as possible, we only select one little part of the big picture that we start with. We drill down into that problem, add more details, get a clarity of what it actually is we are creating, and we leave the rest until later. It is first when we are finished with this little part of the product that we can proceed with detailing the next. One step at a time.

When we do the development, we talk a lot with the customers, get a lot of feedback. We learn a lot, discover things that don’t work and find ways that are better than what we originally imagined. We get a much more accurate picture of the needs. And since we didn’t know this when we started the project, it would have been missing from the project plan. Now instead, we can just bring this knowledge with us when we start planning the next step.

Just think a minute about how this would have affected the old project plan where we already had detailed out what the next step is, Gantts and everything. We now have learned that some of that is wrong, and we have to rework it. So we first write a plan, and then we rewrite it. Sounds like a really smart way to work, no? In Scrum, this is not an issue. No extra time spent, no extra cost to the project, no delays while we wait for the project description to be changed.

What does this look like in real life? Examples please!

Here’s an example of a high-level description. We start with the first step of the planning. Defining the problem we want to solve.

The problem:

We are using paper and pen to do our accounting. This is slow and requires a lot of manual labour to do calculations. It is highly localised, which hampers the collaboration between our local offices.

The solution:

We want to use a digital version of this instead, so we can access the books form anywhere, and have the computers do the calculations for us, which increases the speed and lowers the risk for errors in the calculations.

But obviously, there isn’t enough detail to do anything. So we figure out what is the best thing to start with.

The breakdown:

We need several parts to make this happen.

• A digital version of the ledger, that shows all ledger accounts.
• Some way to add the numbers into it.
• An automatic annual report.
• An automatic calculation of the current cash flow.
• And so on…

Now, what should we start with? Adding numbers to the ledger, but not be able to see them? Or start with the ledger, but only an empty page? We decide that the first thing we want to develop is adding numbers to the ledger, we can always check them directly in the database. And directly after that we will continue with the digital version of the ledger. We think that there is no point in creating an annual report if we don’t have the accounting done, so we will do that later. This will give us a prioritised list of what we currently see we need to do to reach our goal.

The backlog

This is a good time to think of how we formalise this plan in a Scrum project.

The plan in Scrum is what we call a Backlog. It is the list with what we identify when we break down the first step. In this example it is a digital version the ledger, a way to add numbers, the annual report and so on. You know, the list from above.

We need to capture both the high level as well as the details, and in the Scrum Backlog we have three artefacts to do this. Epics, Features and User Stories.

An Epic is the highest level of them all. This is where you describe the project on the top level. For instance: “The accountants need a digital ledger so they can do the accounting daily” or “The shareholders want to see the final financial statement, so they get informed about the state of the company”. Here you can elaborate on these high-level goals.

Each Epic can contain Features. It is like a folder that holds the Features.

We use Features to start adding details to our plan. We add as many Features we need to an Epic to show all the parts that we need to complete it. In the example of “The finance department need a digital ledger so they can do the accounting daily”, it could be to describe the different parts of the ledger, how to add information, correcting when the numbers we added were wrong, what reports we need, and so on.

Finally, we have User Stories. This is the lowest level. This is where the rubber meets the tarmac. At this level, we break down things so it can be developed. There is so much detail that the developers know what they are expected to create.

We still only describe the goal, there is nothing about how to implement it, no choice of technology. And we will not do that either. That is something the team is responsible for. To give an example in the line of the example above: “The finance department needs a way add a new posting in the ledger” and in the following description, it talks about how to choose accounts and what values are allowed, and so on. Nothing like we open a window with one OK and one Cancel button.

Now, the coolest part of all this is that we do not fill the backlog with everything the product ever will do. As I said earlier, we only add as much detail as we need right now. That means that the backlog never is complete, except when the project is finished. But then again, a product is never finished, there will always be more things to do, bugs to fix, changes to add, new laws to comply with and so on.

How to plan in Scrum

A good approach is to start with only headlines for the Epics. Plan out the expectations, build the rough idea of what we’re constructing. Then prioritise them. Then start adding details to the topmost, describe what the goal is.

Then do the same with the Features. Pick the first Epic and write Feature headlines for it. Then prioritise them and add details to the topmost Feature.

Guess what, next thing we do is add headlines for the User Stories in that Feature and prioritise.

Now we can start doing the real work. Describe the user stories the team will start with, in full detail. Or even better. Sit down with the developers and talk about what you want developed and take notes during the session. That way you will have a direct communication without handovers with documents, and the developers can ask questions. They will do that anyway eventually. This way you will find that you also will discover many things that you probably never would have thought of.

Now we’re ready to hand over the baton to the team.

And while the team starts cranking out code for the user stories, we move along to the next Feature. And then the next. Until we have finished all the features, including the ones we discover we need in the process. And when this Epic is done, we continue with the next Epic. And so on, and so on, and so on.

This principle has been used for many years in manufacturing. I think they call it Just in Time Inventory. You know, only keep as much in stock that you can sell right now. Do not produce everything you will sell for the coming year. It’s just ties up cash. And what if you discover something that is wrong with the product and have to make a recall? Expensive!

It’s the same principle here.

Good luck with your next plan!

Cheers!

Photo by: Startup Stock Photos via Pexels.