Scrum and XP From The Trenches ^{2nd Ed.}

The tricky part to agile software development is that there is no manual telling you exactly how to do it. You have to experiment and continuously adapt the process until it suits your specific situation.

This book aims to give you a head start by providing a detailed down-to-earth account of how one Swedish company implemented Scrum and XP with a team of approximately 40 people and how they continuously improved their process over a year's time.

Under the leadership of Henrik Kniberg they experimented with different team sizes, different sprint lengths, different ways of defining "done", different formats for product backlogs and sprint backlogs, different testing strategies, different ways of doing demos, different ways of synchronizing multiple Scrum teams, etc. They also experimented with XP practices — different ways of doing continuous build, pair programming, test driven development, etc, and how to combine this with Scrum.

This book includes:

• Practical tips and tricks for most Scrum and XP practices
• Typical pitfalls and how they were addressed
• Diagrams and photos illustrating day-to-day work
• Testing and test-driven development
• Scaling and coordinating multiple teams
• Dealing with resistance from inside and outside the team
• Planning and time estimation techniques

This second edition is an annotated version, a "director's cut" where Henrik reflects upon the content and shares new insights gained since the first version of the book.

• Foreword by Jeff Sutherland
• Foreword by Mike Cohn
• Intro
• Disclaimer
• Why I wrote this
• But what is Scrum?
• How We Do Product Backlogs
• Additional story fields
• How we keep the product backlog at a business level
• How We Prepare For Sprint Planning
• How We Do Sprint Planning
• Why the product owner has to attend
• Why quality is not negotiable
• Sprint planning meetings that drag on and on…
• Sprint planning meeting agenda
• Defining the sprint length
• Defining the sprint goal
• Deciding which stories to include in the sprint
• How can product owner affect which stories make it to the sprint?
• How does the team decide which stories to include in the sprint?
• Why we use index cards
• Definition of "done"
• Time estimating using planning poker
• Clarifying stories
• Breaking down stories into smaller stories
• Breaking down stories into tasks
• Defining time and place for the daily scrum
• Where to draw the line
• Tech stories
• Bug tracking system vs product backlog
• Sprint planning meeting is finally over!
• How We Communicate Sprints
• How We Do Sprint Backlogs
• Sprint backlog format
• How the taskboard works
• Example 1 — after the first daily scrum
• Example 2 — after a few more days
• How the burndown chart works
• Taskboard warning signs
• Hey, what about traceability?!
• Estimating days vs. hours
• How We Arrange The Team Room
• The Design Corner
• Seat the team together!
• Keep the product owner at bay
• Keep the managers and coaches at bay
• How We Do Daily Scrums
• How we update the taskboard
• Dealing with latecomers
• Dealing with "I don’t know what to do today"
• How We Do Sprint Demos
• Why we insist that all sprints end with a demo
• Checklist for sprint demos
• Dealing with “undemonstratable” stuff
• How We Do Sprint Retrospectives
• Why we insist that all teams do retrospectives
• How we organize retrospectives
• Spreading lessons learned between teams
• To change or not to change
• Examples of things that may come up during retrospectives
• Slack Time Between Sprints
• How We Do Release Planning And Fixed Price Contracts
• Define your acceptance thresholds
• Time estimate the most important items
• Estimate velocity
• Put it together into a release plan
• Adapting the release plan
• How We Combine Scrum With XP
• Pair programming
• Test-driven development (TDD)
• Incremental design
• Continuous integration
• Collective code ownership
• Informative workspace
• Coding standard
• Sustainable pace / energized work
• How We Do Testing
• You probably can’t get rid of the acceptance test phase
• Minimize the acceptance test phase
• Increase quality by putting testers in the Scrum team
• Increase quality by doing less per sprint
• Should acceptance testing be part of the sprint?
• Sprint cycles vs acceptance test cycles
• Don’t outrun the slowest link in your chain
• Back to reality
• How We Handle Multiple Scrum Teams
• How many teams to create
• Synchronized sprints — or not?
• Why we introduced a "team lead" role
• How we allocate people to teams
• Specialized teams — or not?
• Rearrange teams between sprints — or not?
• Part-time team members
• How we do Scrum-of-Scrums
• Interleaving the daily scrums
• Firefighting teams
• Splitting the product backlog – or not?
• Code branching
• Multi-team retrospectives
• How We Handle Geographically Distributed Teams
• Offshoring
• Team members working from home
• Scrum Master Checklist
• Beginning of sprint
• Every day
• End of sprint
• Parting Words
• Recommended Reading

An updated version, where the authors admits his mistakes, but it is still very naive and "tech" focused.

With that said, it is a decent introduction to Scrum and XP (mostly Scrum, to be true).