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.