Scrum and XP from the Trenches

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

18 responses on “Scrum and XP from the Trenches

  1. Fabulous article! I think that this is the best (in the sense of "most useful") essay I have read on agile development. The use of common-sense simplicity-rules approaches and discussion of real-world implementation experience is the key. Thank you for taking the time to write this up formally.

  2. Your article really helped our team wrap our heads around a few of the issues we were having with Scrum.

    Questions we had:

    What are the approximate sizes of tasks and backlog items you use?
    Do you restrict estimates based on available time, or some fixed metric? (tasks must be 1/20 of team hours, or must be <1/2 day)
    How granular and specific do you make your backlog items and tasks?
    Do you list all tasks for a given backlog item, or are some implied?


  3. Hi Barrie! Here’s an attempt to answer your questions.

    1) Backlog items for us are usually 1 – 8 days once they get into a sprint.  Tasks are usually 0.5 – 2 days.

    2) We don’t restrict estimates much. We do however use 0.5 days as our lowest level of time estimate granularity for most teams.

    3) We keep backlog items on a quite high level, they are essentially user stories. Tasks are more technical and specific, but we don’t make them verbose. As long as the team knows what the task means it doesn’t need to be described in detail. Also, the timebox of the sprint planning meeting (usually 3 hours) stops us from getting into too much detail.

    4) Most tasks are implied, especially for smaller stories. For larger stories, especially high priority large stories, we try to make a fairly detailed task breakdown. The main purpose of the breakdown is to validate the overall time estimate of the story, and to make it easier for multiple people to work together on the same story.

  4. Hi,

    I am currently ivestigating SCRUM to support our software development process and must say that I found your paper very enlightning and well written.

    Keep up the good work!

    – Waseem

  5. You mention that there is a script available on this site to generate printable index cards from the product backlog.  I have not found it.  Where is it?

    Excellent document, by the way.

  6. Thanks for this article! We have been doing agile development for a while, but have some missing links in the process. I really appreciate your candid real-world sharing of experiences in the subject, it definitely gives a better hint on what’s more effective.

  7. Hi Henrik!

    I’m talking from Brazil… I’m reading the translated book and I would like to ask you: where is the script mentioned in chapter "How we do sprint planning"?

    Thanks in advance,

  8. Hi Henrik

    This book is very wonderful. I learned a lot from it. Could I translate it in Traditional Chinese? (not for business purpose, just try to let more people from Taiwan can learn or study it quickly)


  9. Hi

    Thanks for your response.

    I knew it has “Simplified Chinese” version, but not “Traditional Chinese”. They are different. Simplified Chinese is used in Mainland China and Traditional Chinese is used in Taiwan.

    So, if possible, I hope I can have a chance to translate it in “Traditional Chinese”.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.