Scrum and XP from the trenches, 2nd edition

Last year I sent out a tweet that really took off! It was bit of a joke, mixed with seriousness and a tribute. Here’s how it looked:


To explain, I’m not a big fan of Tolkien (can I say that out loud? 🙂 ) , so I’m totally honest with the statement. It was also a homage to Henrik Kniberg who really started my agile journey. At the company I was working on at the time, we got an introduction to Scrum by one of Henrik’s colleagues from Crisp, and then we set sail. I don’t remember now if I read ”Scrum and XP from the trenches” (first edition that is) before or after the introduction, but this book really started my agile journey; that it was possible to build software without using the waterfall model! Scrum was easily accessible and something we could start to use almost right away.

Scrum and XP from the trenches, 2nd edition (Director’s cut)

A few weeks ago I learnt that the book just had been published in a 2nd edition. It’s the same book as when it was released 2007, but annotated considering the eight more years of Henrik Kniberg’s experience (working together with for example Jeff Sutherland, Mary and Tom Poppendieck, Jerry Weinberg, Alistair Cockburn, Kent Beck, Ron Jeffries and Jeff Patton).


I let Henrik explain the new version by quoting from the preface of the 2nd edition:

”So that’s what the second edition is – an annotated version of the original book. Like a director’s cut. Think of it as me standing behind your shoulder as you read the book, commenting on stuff, cheering you on, with the occasional laugh and groan.”


Since I have previously read the book, and also seen that it has have been downloaded more than 250.000 times, I will not focus on the content from the first edition. Instead I will comment on the annotations entered in the 2nd edition. Basically I wanted answers to the following questions:

  • What has Henrik learnt since 2007
  • How does his experiences compare to mine

I’ve selected seven sections from the book and commented on them using the format of: then, now & my thoughts. Here we go.

1. ”The product backlog is the heart of Scrum”
Then: The product backlog was a file in Excel that (almost) only one person cared about, the product owner.
Now: A good product starts with customer needs and thoughts how to fulfill those needs. The backlog then is a (cloud) shared document that all in the team are involved in, and take responsibility for.
My thoughts: The product backlog is really ”the map forward” and all stakeholders needs to be able to access it easily. Therefore we use the priority pyramid to visualize our backlog.

2. ”Sprint planning is a critical meeting, probably the most important event in Scrum”
Then: The sprint planning meeting kicks off the following sprint and a badly performed sprint planning leads to a poorly executed sprint, according to the saying: ”shit in, shit out”.
Now: Still an important meeting, but not the most important in Scrum.
My thoughts: More important are to conduct retrospectives regularly to be able to continuously improve the process, this is also called kaizen. We have kaizen-meetings for all the teams 30 minutes every Friday to discuss the past week, what is working good, what needs to be improved etc. We keep track of our improvements using a Kaizen-board.

3. Focus factor
Then: ”Available man days” multiplied by the ”focus factor” was used to calculate the team’s ”estimated velocity” for the sprint.
Now: As Henrik writes, he wants to ”rip out these pages” from the book. This way of calculating is not used anymore! Instead, use data from past sprints. For example select the same amount of stories that was completed in the last sprint as a target for the upcoming.
My thoughts: This is painful reading. All the sprint planning meetings I have been in, that spent time on estimating and then trying to fit the scope (that we wanted to do) into the length of the sprint. We fooled ourself with manipulating the focus factor (this sprint ”we will reach” a focus factor of 80%, despite we have never done it earlier…), or ”can we expand just this sprint to six weeks?” to fit everything in. Luckily we don’t do this anymore 🙂

4. Definition of done
Then:  The product owner and the team agreed on a clear definition of done for each story.
Now: A concrete check list is used instead.
My thoughts: We have criterions for each of the columns in our team boards. Those have to be fulfilled before the task can move on to the next column/step in the process.

5. Avatars
Then:  The name of the person working on the task was written on the sticky.
Now: Avatars are being used instead. Each team member pick something that represents them, print it and put it on magnets.
My thoughts: We used to write names on the stickies. Since several persons usually works with one task during the flow through the process the stickies got messy towards the end. Now we use magnets with pictures or the initials of the team members printed on them.

6. Burn-down chart
Then: Scrum was originally done for teams doing one-month sprints and using Excel to track the tasks. The burn-down chart (also produced in Excel) was vital to see the progress of the sprint.
Now: Since most teams do shorter sprints (2-3 weeks) the board itself (with stickies in different columns) is enough for other stakeholders to understand ”where the team are”. Burn-down charts can be skipped.
My thoughts: We never got burn-down charts to work properly, and we struggled a lot with it. You can read more about that here.

7. Bad approach: ”Focus on building new stuff”
Then:  The bad approach was to focus on building new stuff rather than getting ”old” (= already completed stuff) into production.
Now: Still the same problem. Henrik says that solving this problem (by limiting the number of features in process at the same time) he have seen companies become seven times faster.
My thoughts: The saying ”Stop starting, start finishing” doesn’t seem to take effect. Is it human nature that it is ”more fun” to start new stuff rather than completing ”old” ongoing work? I don’t know, all I can do is to agree that this is still true.


With the new annotations in this second edition I can really recommend you to read this book! Best of all? You can make your own judgement by downloading the book for free and read it yourself! I let Henrik end with another quote that sums up his agile experiences:

”I’ve found some strong common denominators though: work in cross-functional teams, visualize things, deliver often, involve real users, automate your tests and release process, and experiment a lot. The basic agile principles, really.”

All the best,
 Tomas from TheAgileist


Jeff Sutherland, the co-creator of Scrum, has written a new book called ”Scrum” with the subtitle ”The Art of Doing Twice the Work in Half the Time”. The book was released in September 2014. First of all, this book is not a book for those of you currently using Scrum (or it could be, more about that later). This book is written to take Scrum beyond being used only for software development. Jeff Sutherland (and his son that has done the writing) is ”banging on the big drum” and sending a somewhat simplified message about Scrum, at least in my opinion.



I will not tell you one of my own stories under this paragraph, as I have done in other reviews. Why not? Because the book is full of stories as it is! You can even call it anecdotical. I don’t see this as a bad thing though, I like to read about, for example, Jeff’s life and how Scrum was born.


The book is divided into nine chapters and one appendix. The appendix is called ”Implementing Scrum – How to begin”, which is the only place ”how” is described (all other parts of the book focus on ”why”). Here are the chapters described in a little more detail.

Chapter One: The Way the World Works Is Broken
Jeff makes the obvious attack on Waterfall and tells the story about ”Fixing the FBI” with Scrum. References to Taiichi Ohno’s TPS (Toyota Production System).

Chapter Two: The Origins of Scrum
This chapter tells the story of the birth of Scrum and how robots (!) where involved. As many of the things in Lean and Agile the original ideas and concepts came from Japan.

Chapter Three: Teams
The ultimate size of a team is seven persons +/- two and it shall have the following fulfilled:

  • Transcendent (sense of purpose beyond the ordinary)
  • Autonomous (self-organizing and self-managing)
  • Cross-functional (have all the skills needed to complete the project).

”Adding more manpower to a late software project makes it later.” – Brooks’s Law

Chapter Four: Time
Here are some more stories, how sprint- and ”daily standup”-meetings were invented.

Chapter Five: Waste Is Crime
Starts off with a good sentence ”We’re pattern seekers, driven to seek out rhythm in all aspects of our lives”. What you shouldn’t multitask is also explained and the chapter ends with a very interesting story about judges and sandwiches :).

Chapter Six: Plan Reality, Not Fantasy
The ”Cone of Uncertainty” is shown in this chapter. There is a debate saying that the cone is not corroborated by actual data. The concepts of Fibonacci sequence, Planning Poker, Story and Velocity are explained.

Chapter Seven: Happiness
Jeff introduces the ”Happiness Metric”. A few simple questions that all team members answers after each sprint. What that data a graph can be drawn together with velocity to see how kaizen efforts (continuous improvements) are working out. What are the things that makes people happy? The same things that makes great teams: autonomy, mastery and purpose.

Chapter Eight: Priorities
The OODA loop is explained. It stands for: Observe, Orient, Decide and Act. It’s a variant of PDCA (Plan-Do-Check-Act) that Jeff picked up in the army. The value curve and when to release are also described.

Chapter Nine: Change the World
This last chapter tells Jeff’s thoughts on how we will work in the future. The personal handbook of Valve is mentioned as an example.


I can recommend this book if you want to read the stories about Jeff’s life, the birth of Scrum, and how majors concepts in Scrum were created. If you want to learn Scrum from the beginning there are better books out there.

All the best,
 Tomas from TheAgileist

Scrum – 54 sprints but no takeoff?

In this blog post I will tell you my experiences in using Scrum. It will be fully transparent and I’m not holding anything back. I will share the mistakes and triumphs we had along the way.


A scrum (short for scrummage) is a method of restarting play in rugby football.

Some years ago when the company I work for merged with another, we brought with us the use of Scrum as the framework for software development. They had been using a ”home brewed”-method up until then. Approximately half the development department had previous knowledge of using Scrum, while it was new to the other half. An introduction to Scrum was held for all, but no other formal training, then we kicked off the first sprint.

The result was not a total failure or a huge success, but something in between (to be specific the actual focus factor, calculated after the sprint, was 39%. While the planned focus factor was 70%). The retrospective after the sprint talked about ”everything is new” and ”too much unplanned”. At least is was not as ”unstructured and ad-hoc” as before, so we decided to continue planning and running Scrum sprints.

Here are some of the problems we faced in the following sprints:

  • Stories stalled (from outside dependencies)
  • Fuzzy requirements
  • Poor communication between teams
  • Bad estimates
  • Problem with finding good Scrum Masters for the teams
  • Teams were not kept together for more than a few sprints. We moved around persons between the teams.

We struggled along, now and then we hit some high notes (actual focus factor close to, or above, what was planned before the sprint) but mostly it were between 40-60%. Now you should not just stare blindly on the actual focus factor to deem success or failure, but one problem with not completing your sprint goals is the ”remaining tail of tasks” left after each sprint. If it is just a couple of days of work, it can be fixed in between sprints or included in the next sprint. But if it’s more (say above 10% of the total planned work) people start to question the whole idea with using Scrum. We particularly had one person not seeing the benefits of time-boxing, ”We work and have the sprint open until everything is completed!” (not using the possibility of taking out less prioritized tasks from the sprint to keep the time boxing and the ”steady state delivery” that it gives). The teams were also struggling with finding ”small enough chunks” to deliver in each sprint, almost all stories seemed to span over several sprints with no logical deliveries for each.

The flat line syndrome

To sum up the result from most of our sprints please see the picture below.


Scrum burn-down chart with what I would like to call ”the flat line syndrome”.

What is the syndrome and why is this the end result? In the beginning of the sprint the progress on the tasks are good. All the developers can start working and they feel confident that they are taking steps forward. Often the planning only took half a day (not included in sprint) so the team has a half day ”head start” working with sprint tasks.

In the middle of the sprint dependencies between the tasks starts to occur. To be able to complete task A I need the same methods that are developed in task B, but that is not finished yet. Some type of tasks may also have come to an end in the sprint. For example there are no more GUI tasks to do for the GUI developer. And to ”best use” the GUI developer he or she is fed with other GUI tasks from the Product backlog (not planned in the sprint from the beginning).

At the end of the sprint, we enter a ”third phase”. Now tasks become hard to complete because there are no specific DoD (Definition of Done), written for them. For some reason the first 90% of a task is pretty straight forward, but those last 10% can take ”endless time” to complete. This is human behavior I guess, there is always ”some more things” to fix. Some developers also likes to ”hang on” to a few tasks for a whole sprint to ”polish them to perfection” instead of moving on to another task, i.e., to have the sprint goal in first focus, instead of the specific task.

One other quite common reason for no process (flat line) at the end of the sprint is that the team is not working on the tasks that were planned for the sprint in the sprint planning meeting, The reasons for this:

  • Other tasks (not foreseen on the planning) has emerged when working with the sprint tasks. Those tasks must be fixed first before the actually planned tasks can be attacked.
  • As mentioned, some type of task (like GUI development) has ”gone dry” and therefore developers with that competence (GUI) works with other tasks not planned from the beginning
  • Things have happened. During the time that passed since planning, other tasks with higher priority has emerged that the team must handle ”on the focus factor” (i.e., on the time that was not planned for the sprint. Using a focus factor of 70% for sprint work that leaves 30% for other work).


So what have we learned? Here is a list of thing we should have done better:

  • Use metrics to see if we made improvements over time. Without proper metrics you only have ”gut feeling” if the changes you make is for good or worse
  • Keep the teams together – We learned this after a while, and then we saw real improvements
  • No real continuous improvements (kaizen) to the process. The things that came up on the retrospectives went around in circles (too small teams -> too large teams -> too small teams, too short meetings -> too long meetings -> too short meetings etc.)
  • No proper Scrum training from the beginning.


So I guess you are wondering if we have solved all of our problems using Scrum? The answer is yes, and no. We started to use Kanban instead, all teams wanted to do that.