Scrum: the art of doing twice the work in half the time at  

By JEFF SUTHERLAND 

This book explains a powerful project management system called scrum which combats the major problems with most projects.

The biggest problem with projects is that they try to estimate the entire project in one shot, at the beginning of the project. This estimate is overly detailed, takes weeks to produce and the actual team who’s going to do the work isn’t typically involved.

Afterwards, management thinks that this plan is perfect all we need to do for the project to be successful is to stick to the plan. There is a fundamental problem with this method of estimating a project and it stems from what psychologists call cognitive biases. A cognitive bias is a tendency to think irrationally; to use bad judgment.

Cognitive biases are fundamental flaws of human rationale and they’ve been present with us for thousands of years and we often times are not even aware of them. The first one that we often fall prey to when planning a project is the planning fallacy.

The planning fallacy was first discovered in 1979 by Daniel Kahneman. The planning fallacy is the tendency to underestimate the time it takes to complete a project simply because we vastly underestimate all the influential factors. We tend to be overly optimistic and underestimate a project even if we’re aware of this phenomenon. Jeff Sutherland has seen this in many projects. He finds that estimates of work can range from 400% beyond the time actually taken to 25% of the time taken.

The second combination of cognitive biases we fall prey to you is the sunk- cost and status quo bias. When we spend a lot of time or invest a lot of money creating something, we become attached to it. We resist any change and all new information that might contradict our work. This leads to a delayed response to new information and eventually project overruns. Thankfully there is a better way called a scrum method.

The scrum method is characterized by doing planning in chunks to plan throughout the project and actively seek to improve upon the plan. Major companies are adopting the scrum method. Google, Amazon, Sales force and the FBI all use the scrum method to complete projects.

Jeff Sutherland states that scrum has its origins in the world of software development but now it’s sweeping through myriad other places where work gets done. Everything from building a rocket ship to managing payroll to journalism; scrum accelerates effort. It doesn’t matter what that effort is.

On a typical scrum project, you only see teams that are between three and nine people; a team beyond nine people cannot communicate effectively. This team is responsible for estimating the work. The people that do the work, estimate the work and the team completes work in short work sprints and they aim to demo their work at the end of the work Sprint’s to validate their work and gather feedback.

Here are the seven steps of every scrum sprint.

Step number one is to populate a backlog of all the things you need to do on the project. Don’t make it very detailed. Just list all the items you need to complete on the project. Put them in story format. Each task should read like a narrative: who needs it, what specifically do they need and why do they need it, what they going to use it for. This makes the tasks easier to read and you can hand a task off to anyone and they can start off without a lot of explanation.

During this first step you also prioritize the backlog and you do it in terms of the customer value and the immediate impact that each task will have upon completion. If it’s going to generate revenue right away then that item should be near the top. This first step is done by the product owner who is the visionary for the project’s outcome.

The second step is to estimate each of these tasks relatively by using the Fibonacci sequence. Use the Fibonacci sequence because it’s easier to distinguish between numbers like five and eight as compared to four and five. Humans are great at telling the difference between one, two and three but beyond that it just seems like many. Jeff states that, “don’t estimate in absolute terms like hours. It’s been proven that humans are terrible at that. Size things relatively like t-shirt sizes small medium extra-large or more commonly the Fibonacci sequence.”

The Fibonacci sequence is very common in nature so humans are very used to it. They’ve been used to it for thousands of years. To apply your relative estimate, start with the hardest, longest item. Apply the top end of your Fibonacci sequence range so for this case it would be 13 and then estimate all other items relative to the hardest item.

Step number three is to plan your works sprint. Works prints are typically one to two weeks long. They all must be less than one month long and the goal is to get to a demo date at the end of the work sprint. So you have to determine how many of these points that you’ve assigned to tasks you can complete before the end of the sprint.

Let’s say for this sprint we could do 108 points. It’s an educated guess. After the first sprint you realize that you only completed 96 points. You now use these 96 points as a baseline for future sprints. I like to try and improve upon the initial point value by 10% for all successive sprints.

Step number four is to make your work visible. You do this by creating a scrum storyboard. A simple Storyboard includes three columns. What you’re going to do, what you’re doing and what you’ve done for the sprint. If this was on the wall you would use post-it notes and each post-it note represents a task.  As you start doing it, you move it to the doing column and as you complete it you move to the done column.

Each day you update what’s called a burn down chart. The burn down chart is simply a chart that has an initial sprint point value on the y-axis and you want to subtract from that initial point value each day to at the end of the Sprint. Hopefully down to zero points remaining.

Step number five of a scrum sprint is to do daily 15-minute stand-up meetings. During these meetings you ask “what did we do yesterday, what do we plan to do today and what obstacles are slowing us down? How can we make improvements?” This discussion is led by the scrum leader who’s the facilitator for the team.

Step number six. At the end of your sprint, you demo your minimal Viable Product. It’s a product that has a working feature, not a complete product but something that you can demonstrate. During the demonstration you get feedback from the user: from the customer. The customer will let you know if they approve the feature or they’ll tell you to improve it.

The final step of a scrum sprint is to get your team together and go over what went well last Sprint, what didn’t go well and what improvements can be made to the next sprint. After you’ve identified the things you can improve upon you start the next sprint going back to step 1.

Now why is scrum so powerful? Why is it so much better than existing project management methods? Other than just the original estimate phase there are three core reasons.

The first is that in scrum projects you improve exponentially because you’re having daily stand-up meetings and because at the end of each sprint you need to get feedback and further improve the way you work. These process improvements compound one another like compounding interest and eventually they grow to be massive changes. This is why you can do twice the work in half the time.

The second core reason scrum is better than most projects is that it follows the 80:20 principle. The 80:20 principle states that 80% of the value will come from 20% of the effort or time on a project. Therefore if we look at each sprint as the initial 20% of every project we can in a sense get 80% of the value out of every sprint. We take this can lead to a huge value return far greater than what was initially expected.

The final core reason why scrum’s better than most projects is that the sprints in a scrum are a constraint for your work hours. A typical project requires that you put in some extra hours due to the fact that you aren’t getting the feedback fast enough and you need to catch up. When you work more hours your decision quality goes down. As your decision quality goes down your rework goes up which results in more work for the project which results in more hours and to poorer decisions. It’s a downward death spiral for your project.

So there you have it that’s why scrum is a wonderful project management technique.

If You enjoyed this reading, check out our other book summaries.