Henrik Kniberg - Scrum and XP from the Trenches

2007 C4Media Inc

All rights reserved.

C4Media, Publisher of InfoQ.com.

This book is part of the InfoQ Enterprise Software Development series of books.

For information or ordering of this or other InfoQ books, please contact books@c4media.com.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recoding, scanning or otherwise except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher.

Designations used by companies to distinguish their products are often claimed as trademarks. In all instances where C4Media Inc. is aware of a claim, the product names appear in initial Capital or ALL CAPITAL LETTERS. Readers, however, should contact the appropriate companies for more complete information regarding trademarks and registration.

Managing Editor: Diana Plesa

Library of Congress Cataloguing-in-Publication Data:

ISBN: 978-1-4303-2264-1

Printed in the United States of America

Contents

Acknowledgements

The first draft of this paper took only one weekend to type, but it sure was an intensive weekend! 150% focus factor. :o)

Thanks to my wife Sophia and kids Dave and Jenny for putting up with my asocialness that weekend, and to Sophias parents Eva and Jrgen for coming over to help take care of the family.

Thanks also to my colleagues at Crisp in Stockholm and people on the Scrum Users Yahoo group for proofreading and helping me improve the paper.

And, finally, thanks to all my readers who have provided a constant stream of useful feedback. Im particularly glad to hear that this paper has sparked so many of you to give agile software development a shot!

Foreword by Jeff Sutherland

Teams need to know Scrum basics. How do you create and estimate a product backlog? How do you turn it into a sprint backlog? How do you manage a burn-down chart and calculate your team velocity? Henriks book is a starter kit of basic practices that help teams move beyond trying to do Scrum to executing Scrum well.

Good Scrum execution is becoming more important for teams who want investment funding. As an agile coach for a venture-capital group, I help with their goal of investing only in agile companies that execute agile practices well. The senior partner of the group is asking all portfolio companies if they know the velocity of their teams. They have difficulty answering the question right now. Future investment opportunities will require that development teams understand their velocity of software production.

Why is this so important? If the teams do not know velocity, the product owner cannot create a product roadmap with credible release dates. Without dependable release dates, the company could fail and investors could lose their money!

This problem is faced by companies large and small, new or old, funded or not funded. At a recent discussion of Googles implementation of Scrum at a London conference, I asked an audience of 135 people how many were doing Scrum and 30 responded positively. I then asked them if they were doing iterative development by Nokia standards. Iterative development is fundamental to the Agile Manifesto deliver working software early and often. After years of retrospectives with hundreds of Scrum teams, Nokia developed some basic requirements for iterative development:

Iterations must have fixed time boxes and be less than six weeks long.

Code at the end of the iteration must be tested by QA and be working properly.

Of the 30 people who said they were doing Scrum, only half said they were meeting the first principle of the Agile Manifesto by Nokia standards. I then asked them if they met the Nokia standards for Scrum:

A Scrum team must have a product owner and know who that person is.

The product owner must have a product backlog with estimates created by the team.

The team must have a burn-down chart and know their velocity.

There must be no one outside a team interfering with the team during a sprint.

Of 30 people doing Scrum, only 3 met the Nokia test for a Scrum team. These are the only teams that will receive future investment from my venture partners.

The value of Henriks book is that if you follow practices he outlines, you will have a product backlog, estimates for the product backlog, a burn-down chart, and know your team velocity along with many other essential practices for a highly functional Scrum. You will meet the Nokia test for Scrum and be worthy of investment in your work. If you are a startup company, you might even receive funding by a venture capital group. You may be the future of software development and creator of the next generation of leading software products.

Jeff Sutherland,

Ph.D., co-creator of Scrum

Foreword by Mike Cohn

Both Scrum and extreme programming (XP) ask teams to complete some tangible piece of shippable work by the end of each iteration. These iterations are designed to be short and time-boxed. This focus on delivering working code in a short timeframe means that Scrum and XP teams dont have time for theories. They dont pursue drawing the perfect UML model in a case tool, writing the perfect requirements document, or writing code that will be able to accommodate all imaginable future changes. Instead, Scrum and XP teams focus on getting things done. These teams accept that they may mistakes along the way, but they also realize that the best way to find those mistakes is to stop thinking about the software at the theoretical level of analysis and design and to dive in, get their hands dirty, and start building the product.

It is this same focus on doing rather than theorizing that distinguishes this book. That Henrik Kniberg understands this is apparent right from the start. He doesnt offer a lengthy description of what Scrum is; he refers us to some simple websites for that. Instead, Henrik jumps right in and immediately begins describing how his team manages and works with their product backlog. From there he moves through all of the other elements and practices of a well-run agile project. No theorizing. No references. No footnotes. None are needed. Henriks book isnt a philosophical explanation of why Scrum works or why you might want to try this or that. It is a description of how one well-running agile team works.

This is why the books subtitle, How We Do Scrum, is so apt. It may not be the way you do Scrum, its how Henriks team does Scrum. You may ask why you should care how another team does Scrum. You should care because we can all learn how to do Scrum better by hearing stories of how it has been done by others, especially those who are doing it well. There is not and never will be a list of Scrum best practices because team and project context trump all other considerations. Instead of best practices, what we need to know are good practices and the contexts in which they were successful. Read enough stories of successful teams and

how they did things and youll be prepared for the obstacles thrown at you in your use of Scrum and XP.

Henrik provides a host of good practices along with the necessary context to help us learn better how to do Scrum and XP in the trenches of our own projects.

Mike Cohn,

Author of Agile Estimating and Planning and User Stories Applied for Agile Software Development.

Preface: Hey, Scrum worked!

Scrum worked! For us at least (meaning my current client in Stockholm, whos name I dont intend to mention here). Hope it will work for you too! Maybe this paper will help you along the way.