Henrik Kniberg has put together a ninety page PDF called "Scrum and XP from the Trenches," with Scrum described as "an agile method for project management" on Wikipedia (see "Scrum (management)" and "Scrum (development).") This paper details what Mr. Kniberg found to work for him at his (unnamed) client, "the result of one year's Scrum experimentation in a development team of approximately 40 people."

My current approach to Scrum is the result of one year's Scrum experimentation in a development team of approximately 40 people. The company was in a tough situation with high overtime, severe quality problems, constant firefighting, missed deadlines, etc. The company had decided to use Scrum but not really completed the implementation, which was to be my task. To most people in the dev team at that time, "Scrum" was just a strange buzzword they heard echo in the hallway from time to time, with no implication to their daily work. Over a year's time we implemented Scrum through all layers in the company, tried different team sizes (3 – 12 people), different sprint lengths (2 – 6 weeks), different ways of defining "done," different formats for product backlogs and sprint backlogs (Excel, Jira, index cards), different testing strategies, different ways of doing demos, different ways of synchronizing multiple Scrum teams, etc. We 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 is a constant learning process so the story does not end here. We learned a lot in a year, yet I'm convinced that this company will learn just as much next year (if we keep up the sprint retrospectives) and gain new insights on how to best implement Scrum in this particular context.

He poses the paper as a "war story," to help "turn Principles and Practices into... well.... How Do You Actually Do It." He describes Scrum in quite a bit of detail:

The product backlog is the heart of Scrum. That is where it all starts. This is basically a prioritized list of requirements, or stories, or features, or whatevers. Things that the customer wants, described using the customer's terminology. We call these backlog items today, but in the future we'll probably start using the XP term stories instead. Our backlog items include the following fields:

• ID – a unique identification, just an auto-incremented number. This is to avoid "losing" items when you rename them.
• Name – a short, descriptive name of the backlog item. For example "See your own transaction history." Clear enough so that developers and the product owner understand approximately what we are talking about, and clear enough to distinguish it from other back log items. Normally 2 – 10 words.
• Importance – the product owner’s importance rating for this item. For example 10. Or 150. High = more important.
  • I tend to avoid the term "priority" since in many cases priority 1 is considered the "highest" priority, which gets ugly if you later on decide that something else is even more important. What priority rating should that get – priority 0? priority -1?
• Initial estimate – the team's initial estimate of how long this will take to implement. The unit is "ideal man-days, with ideal team size." Ask the team "if you can take the optimal number of people for this job (not too few and not too many), and lock yourselves into a room with lots of food and work completely undisturbed, after how many days would you come out with a finished, demonstratable, tested, releasable implementation?" If the answer is "with 3 guys locked into a room it would take 4 days" then your initial estimate is 12 ideal man-days.
  • We will probably start calling the unit "story points."
• How to demo – a high-level description of how this backlog item will be demonstrated at the sprint demo. This is essentially a simple test spec. "Do this, then do that, then this should happen."
  • If you practice TDD (test-driven development) this description can be used as pseudo code for your acceptance test code.
• Notes – any other info, clarifications, etc.

It's an excellent document, serving as an adequate introduction to XP and Scrum - and as he says, if you find an element that doesn't work for you, you're quite able to change it to fit your requirements.

Excellent article , well worth a read for anybody experience pain on their project (especially as the delivery deadline approaches) and wondering how they can do better next time. What gives it most weight is that the author is not 'in your face' about trying to sell you something (some whitepapers from Rational come to mind here). Unless of course you're in the market for OO consulting and happen to be based in Sweden ... Even if you're not into Agile / Scrum / XP there's enough in here to convince you (or your boss) to give it a go. Paul , Technology in Plain English

I concur with the previous poster. Excellent article! Sent a link to the PDF to a colleague who does not have much experience of Agile methodologies, but is curious. I think he was quite excited about the article.

Excellent paper. Echo many of the experience and lessons learned from my team. Chester

Thank you Henrik. That was a really great paper filled with a lot of useful content.

This is an excellent doc....very practical Thanks

Very very very good. ciao.

Excellent article. Seems like truly from the trenches. I use monthly sprints and use Wiki for that purpose. There two issues that I seem to grapple with are 1) Wide gap between actual and estmated velocity, especially during the early volatile stage in a project. What should be the window of average past velocity to use for next estimated velocity. 2) As far as the tech items as the author calls them, although ideally they should be tied to a user story, sometimes it's not possible. You are forced to create kind of a "tech story" Pranab

I've read this book at once. It's very nice when people who have wide practical experience share it with others. My team had been using several Scrum practices very similar to those described in the book. But I prefer to keep task board as simple as it possible. So our approach to planning is much more easier.

Hello,
I was the Product Owner from the book and as that a large part of developing all the concepts later described in the book.

As an insider I can say that it is a good description of the processes albeit of course a bit simplified. The book is maybe not sufficient as an introduction to Scrum, but rather for the refinement of the process for an organization already using Scrum.

The area where I don't agree with the theories in the book is the title :-) The successful introduction of Scrum in an organization can't be done internally in the development department, it must be bigger. The result comes from introducing on a product management level, "Scrum by the Generals".

/Linus