Review: Scrum and XP from the Trenches

I am reading the book Scrum and XP from the Trenches by Henrik Kniberg. It is about his personal experience successfully implementing a Scrum-based methodology in his development team of 40 people in Stockholm, Sweeden.

You can read the book as a PDF on InfoQ's web site here: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Or, you can purchase the book at LuLu here:
http://www.lulu.com/content/899349

Review
Here are my comments on each section of the book:

Foreward by Jeff Sutherland

Jeff co-created Scrum. In his foreward he makes these points:

JSG paraphase:

• Scrum is becoming very important to venture capitalists (especially his own partners)
• Teams must know their project velocity -- This is how much of a backlog a team can accomplish in a given sprint. (See http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1110 for details)
• Only teams that match all of the criteria below in the excerpts will be funded by his venture capitalist partners.
  

Direct excerpts:

• 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.
• 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 Burndown Chart and know their velocity.
• There must be no one outside a team interfering with the team
  during a Sprint.
  

Foreward by Mike Cohn

Mike is a founding member of the Scrum Alliance. He has written books, articles, and speaks regularly. Learn more at http://www.scrumalliance.org/profiles/8-mike-cohn.

Mike makes these points:

• Scrum and XP are both practical, results-oriented approaches. They are about Getting Things Done
  
• Prototype early and often rather than documenting requirements at an exhaustive level
  
• Avoid excess modeling, prefer prototyping instead
• Work on things that have potential to become part of the actual working solution
  
• Refer to other resources for the theory behind Scrum. It is out there, but this book focuses on implementing Scrum successfully

Preface

• He was skeptical going in, but was convinced shortly thereafter starting
• Scrum worked for the author's 40 person team
• Team's quality was way below acceptable, but implementing Scrum solved their problems
• He will use Scrum by default for new projects in the future unless there is a specific reason not to use it
  

1. Introduction

• Scrum is not a magic bullet
• You tailor it to your context
• His team was fighting fires all the time
  
• Quality was low
• Overtime was up
• Deadlines were missed
• "Scrum" was just a buzzword to most people
• Implemented across teams of 3 to 12 people
• Learned about different ways of managing backlog (Excel, Jira, index cards, etc)
  
• Experimented w/different sprint sizes (2 to 6 weeks)
• Used other XP practices like pair programming
• Used continuous integration
• Used TDD
• Took Ken's certification course
• Most useful info came from real "War Stories" and case studies of people actually solving problems with Scrum
  

2. How we do product backlogs

• Backlog is hear and soul of Scrum
• Backlog contains customer's desired features, prioritized by most critical
• Call the backlog items User Stories or just Stories
• ID, Name, Importance, Initial Estimate, How-To-Demo, Notes
• 6 fields were most often used
• Kept in Excel spreadsheet on shared drive with Multiple Editing allowed
• Additional: Track, Components, Requestor, Bug Tracking ID if needed
• Keep the product backlog at the Business Level not a technical level
• Let the team figure out the How-To Technical Level
• Ask Why as many teams as needed to get to the underlying intent if the Product Owner does state it in technical terms, and move technical language to Notes field.
  

3. How we prepare for Sprint planning

• Product Backlog MUST exist first in ship-shape form
• One Product Backlog and One Product Owner per Product
• All items should have a unique Importance level
• Leave large gaps. 100 does not mean 5 times more important than 20. Easier than making 20.5 if you did 20 and 21 instead when item C comes up in the middle
• Product Owner should understand the intent of each story
• Others can add stories, but only Product Owner can assign importance
• Only the team can add an estimate
• Tried using Jira for keeping the backlog, but too many clicks for Product Owner
• Have not yet tried VersionOne or other Scrum tools

4. How we do Sprint planning

TODO page 25

5. How we communicate Sprints

6. How we do Sprint backlogs

7. How we arrange the team room

8. How we do daily Scrum

9. How we do Spring demos

10.How we do Spring retrospectives

11.Slack time between Sprints

12.How we do release planning and fixed priced contracts

13.How we combine Scrum with XP

14.How we do testing

15.How we handle multiple Scrum teams

16.How we handle geographically distributed teams

17.Scrum master checklist

18.Parting words

Recommended reading