Tag Archives: xp

Japanese version of Scrum and XP from the Trenches

Posted on by

Here’s a Japanese translation of my book Scrum and XP from the Trenches. Thanks Shoichi Goto!

Japanese version of Scrum and XP from the Trenches

A Spanish version of the book is also available. Korean, Portuguese, German, Chinese, French, and Slovak translations are underway. I’m impressed by the agile community!

All translations will soon be listed on InfoQ. Feel free to email me (henrik.kniberg AT crisp.se) if you want to translate the book to your language.

Chinese version of Scrum and XP from the Trenches

Posted on by

Here’s a Chinese translation of my book Scrum and XP from the Trenches. Thanks Jacky Li!

Chinese version of Scrum and XP from the Trenches

A Spanish and Japanese version of the book is also available. Korean, Portuguese, German, French, and Slovak translations are underway. I’m impressed by the agile community!

All translations will soon be listed on InfoQ. Feel free to email me (henrik.kniberg AT crisp.se) if you want to translate the book to your language.

Spanish version of Scrum and XP from the Trenches

Posted on by

Here’s a draft version of the Spanish translation of my book Scrum and XP from the Trenches. Good work Ángel Medinilla!

Chinese, Korean, German, and Japanese translations are underway, I’ll let you know when they are done.

UPDATE (June 10): Within 1 day of publishing this blog entry I received an offer to translate the book to German and 2 separate offers to translate the book to French. Free of course. What a community! Heartwarming :o)

Scrum and XP from the Trenches in Spanish

Top 3 Tools your Scrum team can’t live without

Posted on by

Here are top three tools for any Scrum project

1. Google Spreadsheets   Your backlog, anywhere & anytime. A perfect lean alternative to your Scrum board on the wall. Anywhere & anytime.
2. Confluence Wiki   Atlassian Confluence, wiki as simple as it gets. Any user can get going in this user friendly tool.
3. Trillian chat   Hooks up with MSN, ICQ and Yahoo. Hold live discussions going across sites. Just waiting for that Skype plugin..

10 ways to screw up with Scrum and XP

Posted on by

Here are the slides from my session "10 ways to screw up with Scrum and XP", from the JavaForum conference in Malmö.

I’ve done this session at other conferences, but updated the slides a little bit each time. Interesting that so many people like to hear about how to get it all wrong :o)

Agile version control with multiple teams

Posted on by

Here’s a paper describing a strategy for version control with multiple teams in an agile environment. It is hosted on InfoQ. Enjoy!

Agile version control with multiple teams

Dealing with technical debt

Posted on by

Technical debt is a metafor created by Ward Cunningham to describe situation where shortcuts taken in the software process  will bites us back. Read Martin Fowlers excellent summary if you want do dig in on the subject.

There are many reasons for occurrence of technical debt, and not all are bad. A start up company for example might need to deploy pre maturely in order to finance it’s existence.

The problem arises when a team needs slack from their product owner to deal with technical debt. It might not always strike the product owner as a good deal, especially since the tech stuff are mostly makes sense to the developer more that  to the product owner.

If unlucky, the constant need to explain yourself can move the team into a deadlock where improvements don’t take place. To prevent this, here is an alternative approach!

Define actions to remove technical debt as any work made to fix the seven wastes of software developments.

  • Extra features
  • Partially done work
  • Extra efforts (discarded knowledge, reversed descisions)
  • Handoffs
  • Task switching
  • Delays
  • Defects

So whenever you do work of technical debt and your product owner asks you what you did, link it to one of the wastes of software development.

Scrum in the large – demystify roadmaps and progress tracking

Posted on by

A good thing with Scrum is that it helps the team focus on short term goals instead of dealing with big tasks with dubious value.  But we cannot either resign and give up long range visibility of where we are heading with the excuse of “we are doing Scrum”.

The latter is dangerous since we are not alone in building the business value of software.  Sales, marketing, support, third parties  -all need to work together to make the software a successful business value.

Pull in the same direction

If we only provide "next sprint" visibility your Marketing manager might – after one year silent resistance of your Scrum trial – go ballistic about lack of date visibility and lobby for a return to the waterfall/Gantt approach.

So let’s demystify the roadmap: a roadmap should help you all pull in same direction.

If you can get all surrounding parties to attend your sprint demo and sprint planning, you have come a long way. But in many cases that is impractical, you would simply be to many or you might loose focus (having to explain details of scrum instead of doing actual planning for example).

A typical roadmap would stretch for about six months. If should provide the overall view as of the release dates of your sprints and the expected content (user stories).

The trick is to demystify the date and content relationship.  By providing visibility in the planned dates for the sprints, the actual content in the sprints might actually matter less. You can move to a more fruitful discussion of “what happens if" (we switch the order of sprints, or move this story )..  Instead of  “I have no clue in what you guys are doing” .

A simple roadmap at sprint 1 could look like:

Sprint 1 Roadmap

Now after sprint 2 things change. A new competitor makes us revaluate the sprint content, order tracking switches between sprint 3 and sprint 4:

Roadmap before Sprint 3 

And since we publish the roadmap on a website or accessible place, we no longer need to provide tedious status reports!

Suggestions where to keep your roadmap:

  •     Published to a web server using Excel
  •     In a Google Spreadsheet
  •     On the wall of your coffee room

Happy Scrumming!

10 ways to screw up with Scrum and XP

Posted on by

Here are the slides from my session "10 ways to screw up with Scrum and XP", from the JFokus conference in Stockholm.

How to catch up on test automation

Posted on by

(this entry is now available as an article on the scrum alliance site as well)

The test automation problem

Many companies with existing legacy code bases bump into a huge impediment when they want to get agile: lack of test automation.

Without test automation it is very hard to make changes in the system, because things break without anybody noticing. When the new release goes live, the defects are discovered by the real users, causing embarrassment and expensive hotfixing. Or even worse, a chain of hotfixes because each hotfix introduces new unanticipated defects.

This makes the team terribly afraid to change code, and therefore relucant to improve the design of the code, which leads to a downward spiral of worse and worse code as the system grows.

What to do about it

Your main options in this case are:

  1. Ignore the problem. Let the system decline into entropy death, and hope that nobody needs it by then.
  2. Rebuild the system from scratch using test-driven development (TDD) to ensure good test coverage.
  3. Start a separate test automation project where a dedicated team improves the test coverage for the system until it is adequate
  4. Let the team improve test coverage a little bit each sprint.

Guess which approach usually works best? Yep, the last one – improve test coverage a little bit each sprint. At least in my experience.

The third option may sound tempting, but it is risky. Who’s going to do the test automation? A separate team? If so, does that mean the other developers don’t need to learn how to automate tests? That’s a problem. Or is the whole team doing the test automation project? In that case their velocity (from a business perspective) is 0 until they are done. So when are they done? When does test automation “end”?

No, let’s get back to the fourth option. Improve test coverage a little bit each sprint. So, how to do that in practice?

How to improve test coverage a little bit each sprint

Here’s an approach that I like. In summary:

  1. List your test cases
  2. Classify each test by risk, how expensive it is to do manually, and how expensive it is to automate
  3. Sort the list in priority order
  4. Automate a few tests each sprint, starting from the highest priority.

Step 1: List your test cases

Think about how you test your system today. Brainstorm a list of your most important test cases. The ones that you already execute manually today, or wish you had time to execute. Here’s an example from a hypothetical online banking system:

Change skin
Security alert
See transaction history
Block account
Add new user
Sort query results
Deposit cash
Validate transfer

Step 2: Classify each test

First classify your test cases by risk. Look at your list of tests. Ignore the cost of manual testing for the moment. Now what if you could throw away half of the tests, and never execute them? Which tests would you keep? This factor is a combination of the probability of failure and cost of failure.

Highlight the risky tests, the ones that keep you awake at night.

Test case Risk
Change skin
Security alert  x
See transaction history
Block account  x
Add new user
Sort query results
Deposit cash  x
Validate transfer  x

Now think about how long each test takes to execute manually. Which half of the tests take the longest? Highlight those.

Test case Risk Manual test cost
Change skin
Security alert  x
See transaction history  x
Block account  x x
Add new user
Sort query results  x
Deposit cash  x
Validate transfer  x  x

Finally, think about how much work it is to write a automation scripts for each test. Highlight the most expensive half.

Test case Risk Manual test cost Automation cost
Change skin  x
Security alert  x  x
See transaction history  x
Block account  x  x
Add new user
Sort query results  x  x
Deposit cash  x
Validate transfer x  x  x

Step 3: Sort the list in priority order

So, which test do you think we should automate first? Should we automate “Change skin” which is low-risk, easy to test manually, and difficult to automate? Or should we automate “Block account” which is high risk, difficult to test manually, and easy to automate? That’s a fairly easy decision.

But here’s a more difficult decision. Should we automate “Validate transfer” which is high-risk, hard to test manually, and hard to automate? Or should we automate “Deposit cash” which also is high-risk, but easy to test manually and easy to automate? That decision is context dependent.

You basically need to make three decisions:

  • Which do you automate first? The high risk test that is easy to test manually, or the low risk test that is difficult to test manually?
  • Which do you automate first? The test that is easy to do manually and easy to automate, or the test that is hard to do manually and hard to automate?
  • Which do you automate first? The high risk test that is hard to automate, or the low risk test that is easy to automate?

Those decisions will give you a prioritization of your categories, which in turn lets you sort your list of test cases by priority. In my example I decided to prioritize manual cost first, then risk, then automation cost.

Test case Risk Manual test cost Automation cost
Block account  x  x
Validate transfer  x  x  x
See transaction history  x
Sort query results  x  x
Deposit cash  x
Security alert  x  x
Add new user
Change skin  x

So that’s it! A prioritized backlog of test automation stories.

You could of course also invent some kind of calculation algorithm. A simple such algorithm is that each highlighted cell = 1 point. Then you just add upp each row and sort. Or just sort the list manually using gut feel.

You could also use a more specific unit for each category, if my simple binary scheme isn’t sufficient.

Test case Risk
Manual test cost
Automation cost
(story points)
Block account high 5 hrs 0.5 sp
Validate transfer high 3 hrs 5 sp
See transaction history medium 3 hrs 1 sp
Sort query results medium 2 hrs 8 sp
Deposit cash high 1.5 hr 1 sp
Security alert high 1 hr 13 sp
Add new user low 0.5 hr 3 sp
Change skin low 0.5 hr 20 sp

Remember though that our goal for the moment is just to prioritize the list. If you can do that with a simple and crude categorization scheme then there’s no need to complicate things right? Analysis is useful but over-analysis is just a waste of time.

Step 4 – Automate a few tests each sprint

Irregardless of the stuff above, each new product backlog story should include test automation at the story level. That’s the XP practice known as “customer acceptance tests”. Not doing that is what got your system into this mess in the first place.

But in addition to implementing new stories, we want to spend some time automating old test cases for other previously existing stories. So how much time do we spend? The team needs to negotiate that with the product owner. The agreement will typically take on one of the following forms:

  • “Each sprint we will implement one test automation story”
  • “Each sprint we will implement up to 10 story points of test automation stories”
  • “Each sprint we will spend about 10% of our time implementing test automation stories”
  • “Each sprint we will finish the product backlog stories first, and then spend the remainder of the time (if any) implementing test automation stories”
  • “The product owner will merge the test automation stories into the overall product backlog, and the team will treat them just like any other story.”

The exact form of the agreement doesn’t matter. You can change it every sprint if you like. The important thing is that the test automation debt is being gradually repaid, step by step.

After finishing half the stories on your test automation backlog you might decide that “hey, we’ve paid back enough debt now! Let’s just skip the rest of the old test cases, they’re not worth automating anyway”, and dump the rest. Congratulations!

So this solves the problem?

Wishful thinking. No, this pattern doesn’t magically solve your test automation problem. But it makes the problem easier to approach :o)

Scrum success stories

Posted on by

Scrum isn’t the only agile method (see my article Scrum and XP work well together), but seems to be one of the best ways to get started. As I mentioned in Failing with Scrum, Scrum is no silver bullet. It doesn’t guarantee success, but it improves the odds.

Over the past few years I’ve been involved in dozens of Scrum projects, directly or indirectly. Interestingly enough, every single case that I can remember has been successful (maybe I just have selective memory…)! The client has been happy with the process and wants to continue using Scrum in future projects.

In most cases Scrum has resulted in immense improvements. Based on interviews, most improvements are within the following areas:

  • business focus
  • productivity
  • product quality
  • team motivation
  • transparancy & knowledge spread

In some cases Scrum has resulted in only minor improvements, i.e. the client is only slightly better off than before.

In one case a client aborted a project shortly after introducing Scrum, but they considered it a success since Scrum helped them discover early that the project was doomed to fail (described in more detail in Failing with Scrum).

No clients so far have gone back to their previous process. On the contrary, every company that I’ve worked with has decided to ramp up and use Scrum on other projects as well. Several have decided to go "company wide" and introduce Scrum, lean and agile techniques throughout all layers in the company.

Here’s a quote from an email I received today (from one of my readers, not a client):

At this point I can already proudly mention, that the project has been just like in a fairy tale. We were able to finish the implementation well ahead of schedule and with a quality that has surprised many. One good indicator of successful first-ever-Scrum-project is that today all of our project managers have either completed or signed up for a Certified Scrum Master course. I bet we’ll soon have a few more Scrum projects running 😉

Best part any way is, that the developers seem to love Scrum (just as you mentioned).

Thanks again for writing the book, it helped us a lot!

My book Scrum and XP from the trenches describes concrete agile techniques used in a handful of different projects within a single company. Some of the techniques failed, but we inspected and adapted and each project was a success, even those that seemed very bleak and uncertain at the outset.

After publishing the book I’ve received literally hundreds of emails from people using Scrum and/or XP, including many companies that were inspired to give agile software development a shot after reading the book. Very good to hear!

The book was not intended to be a "manual" or "cook book" for Scrum and XP – it was intended to be a case study with detailed examples. Although I stated that quite clearly in my disclaimer, many companies have nevertheless used it as a cook book and implemented Scrum exactly as described in the book. To my surprise, they have done well! Even in totally different contexts. The context of the book is a gaming software company, but I’ve received reports from companies building things such as flight control software and embedded software using the same process and techniques, and it has worked well!

I still don’t recommend using my book as a manual. I’m still dreading the email "Hi Henrik, we found your book and have implemented everything as described. And now the project went to hell and we’re going to sue you! Our software caused the nuclear plant to explode. See you in court!". But it hasn’t happened yet…

After all this positive feedback, and a complete lack of negative feedback, I’ve made some new conclusions:

  • Scrum appears to work very well in a very broad range of contexts
  • Some implementation patterns (= concrete techniques) are quite universal and can be applied in almost any context. I used to think they were more context dependent. For example:
    • Physical taskboards
    • Planning poker
    • Combining Scrum and XP
    • … and many more
  • Copying another company’s implementation is a good idea. But it should be seen as a starting point only. A code example. A template from which to evolve.
  • Make sure you have a coach. Doesn’t necessarily need to be an external coach, just  make sure you have somebody in the building who’s done this stuff before.

Index card generator – version 2!

Posted on by

Many people use a spreadsheet to house their Scrum Product Backlog. That works quite fine. However, during sprint planning meetings it is usually much more effective to use physical index cards. See my book Scrum and XP from the Trenches for the reasoning behind this.

Here’s a simple tool that generates printable index cards in A5 format directly from your Excel-based product backlog. Thanks Stefan Nijenhuis for making this available!

There is nothing to install. This is simply an Excel document containing a product backlog and a “generate index cards” button.

For more info, see the readme inside the document.

This version requires only Microsoft Excel. The previous version required both Excel and Access.

Update (2008-01-04)

Here’s another excel-based index card generator from Claudio Gambetti. Contains a few extra features such as tracks (a.k.a. themes) and components, as mentioned in my book. You choose your flavor. Thanks for contributing this Claudio!

Update (2011-06-23)

Here’s another version from Nathalie Beauguerlange. He says:

“I have made a little modification on it, because the cards were a bit too large for our scrum board, so I’ve resized the template and changed the cards number per page, allowing me to print 4 cards per A4 format page, so that we can use less paper.”

Update (2011-06-28)

Here’s a Google Docs version of this tool (and instruction video), for those who use Google Spreadsheets to house their backlog. I usually prefer Google Spreadsheets over Excel, since it is multiuser and in the cloud. And requires no installation. And no payment :o)

Thanks David Vujic for making this available.

Scrum and XP from the Trenches – now on Amazon

Posted on by

Scrum and XP from the Trenches is now listed on Amazon.com. (as well as on InfoQ).

If you liked the book then go submit a review on Amazon :o)

Best Speaker award :o)

Posted on by

Cool, I was awarded Best Speaker at the Bits & Chips conference in The Netherlands :o)

Never would have expected that, considering there were more than 50 other speakers!

I did a brief talk about "Bootstrapping Scrum and XP", with an audience of about 150 people. Decided to open with 15 minutes of  "The fastest possible introduction to lean & scrum & XP" as well since I was first out on the agile track, maybe that’s what people liked.

Agile toolkit

Posted on by

An agile coach should never leave home without his Agile Toolkit!

Mine is much sloppier. The pretty one above belongs to my co-coach David Barnholdt.

10 ways to screw up with Scrum and XP

Posted on by

Here are the slides for my presentation 10 ways to screw up with Scrum and XP. The slides are (as usual) mostly pictures and few words so they may be a bit confusing if you weren’t at the presentation :o)

Scrum and XP fit together

Posted on by

Most people in the industry seem to agree that Scrum and XP complement each other. Jeff Sutherland and Ron Jeffries agree that it is a good idea to start with Scrum and then let XP follow naturally (since Scrum teams are self-managing and can choose whatever engineering methods they like).

Here’s a quote from Ron and Jeff’s Deep Agile course:
"You don’t see high performing Scrum teams without XP engineering practices.  It is difficult to scale XP teams without Scrum and Scrum solves the management interface issues for XP.  Be careful about doing pieces of anything and calling it Agile."

Mike Cohn and Robert C Martin believe (or hope) that these will merge together into some kind of "unbranded Agile". Mike’s take is that this will simply be called "the way we do software".  (Based on personal discussions with both of them)

2nd Annual State of Agile Development Survey shows the following statistics for Scrum & XP adoption:

  • Scrum: 37%
  • Scrum + XP: 23%
  • XP: 12%

This is of course a matter of definition (i.e. how much of XP do you have to do for it to count in this survey?). But the message is still quite clear.

Personally I believe that many of the "scrum only" companies in that survey are in fact using many of the XP practices under the radar.

So what’s your guess for next year’s survey? My guess is 30% Scrum, 40% Scrum+XP, 10% XP.

This picture illustrates how they fit together. Scrum can be seen as the interface between the team and the stakeholders. Scrum leaves a hole in the middle, i.e. how the team should do their daily work, which XP fills in quite nicely. Once Scrum is in place the team is self-managing and can choose how to do their work. However, Scrum places fairly strict requirements (such as delivering working tested software every iteration) making XP a natural choice for many teams.

Agile (a.k.a. adaptive or empirical) software development is all about feedback cycles. Scrum and XP complement each other very nicely here, as shown in the picture below (yellow = XP, green = Scrum). There is a slight overlap in that both XP and Scrum advocate daily meetings, which is no problem really.

Small circle = short feedback cycle.

On one end of the scale, pair programming gives a feedback cycle of a few seconds, where defects are detected and fixed within seconds ("hey, isn’t that supposed to be a 3?") . This is a "are we building the stuff right?" feedback cycle.

On the other end of the scale, Sprint demo gives a feedback cycle of a few weeks. This is a "are we building the right stuff?" feedback cycle.

JAOO tutorial slides

Posted on by

For those of you who attended my Scrum & XP tutorial at the JAOO conference, here are the slides:


Thanks for attending, hope you had a good time! Despite my piano playing (how can I resist a grand piano standing in the corner of the room :o)

I thought the attendance would be like 7 or 8 people, considering it was Friday afternoon after a long hard conference week. So I was very surprised to see 45 faces there! I sat with Jeff on the bus back to the airport, turned out that he was the one who had been telling everyone to go :o)

Anyway good luck and happy Scrumming and XP-ing!


Scrum and XP from the Trenches – printed version available on InfoQ

Posted on by

Scrum and XP from the Trenches is now available on InfoQ, with forwards by Mike Cohn and Jeff Sutherland :o)

The printed version costs $22.95, the online version is free but requires registration on InfoQ. My older PDF version is hereby deprecated, so if you have any links please update to the InfoQ version!

Registration at InfoQ is simple and quick, I can strongly recommend it. InfoQ is an excellent site with new and interesting content added every day, and smart personalization features. The checkboxes to the left let you instantly filter the content to match your tastes.

Planning Poker

Posted on by

I’ve written up a page with a pretty graphical summary of what Planning Poker is.


Planning poker

Scrum and XP from the Trenches – version 2.0

Posted on by

I finally found time to create version 2.0 of "Scrum and XP from the Trenches" :o)

No revolutionary changes. Just wanted to clarify some chapters, add some missing info, and add some new knowledge gained since the first version.

  • Added a chapter on planning poker.
  • Added a chapter on how the team decides which stories to include in a sprint & what the product owner can do to affect this.
  • Clarified how we use velocity metrics in sprint and release planning.
  • Added a chapter on what to do if the product owner doesn’t want to attend the sprint planning meeting.
  • Added a chapter describing why quality is non-negotiable.
  • Added a better picture of the design corner.
  • Added more details on how we do retrospectives, including a whiteboard photo.
  • Added more on offshoring and distributed teams.
  • Lots of minor corrections and clarifications.

Enjoy! And thanks for all the valuable feedback.

Ivar Jacobson gör en pudel!

Posted on by

Ivar Jacobson, Pan-Wei Ng, och Ian Spence har just publicerat en ganska lång artikel i DDJ med namnet Enough of Processes: Let’s Do Practices, Part I. Det är, förvånande nog, ett ganska ärligt erkännande att dagens processer för mjukvaruutveckling inte fungerar.

In the first installment of this two-part article, we examine the issues facing the current generation of processes and show why we have all had enough of them.

Ett ganska häpnadsväckande uttalande från skaparen av RUP! Artikeln räknar upp många anledningar till varför processer i dagens mening har problem, och presenterar sedan en teaser till något de kallar Practices, men väntar med att förklara vad de menar till den ännu opublicerade Part II av artikeln.

I någon mening är det kanske intressant vad de har i kikaren, men det verkar trots allt som om de egentligen inte vet vad de talar om.

The industry is not really getting any better at developing software

Really? Jag tycker Scrum, XP och TDD är väldigt tydliga och rejäla steg i rätt riktning.

Scrum and XP from the Trenches

Posted on by
Cover pageI’ve written a paper for those of you that are interested in agile software development:

Scrum and XP from the TrenchesHow we do Scrum

It describes lessons learned after a year of experimentation with a 40-person development team.


  • How we do product backlogs
  • How we do sprint planning
  • How we communicate sprints
  • How we do sprint backlogs
  • How we arrange the team room
  • How we do daily scrums
  • How we do sprint demos
  • How we do sprint retrospectives
  • How we do release planning and fixed price contracts
  • How we combine Scrum with XP
  • How we do testing
  • How we handle multiple scrum teams
  • How we handle geographically distributed teams