Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Wednesday, November 29, 2006

Scrum and XP from the Trenches

Henrik Kniberg has published a PDF called Scrum and XP from the Trenches. It's a well written and engaging read on his experiments, successes, and challenges running a development team of about 40 people using Agile methods.

One thing I found quite interesting was the information that his team felt was most useful to document user stories (or backlog items). They used various tools, including a shared Excel spreadsheet, to track the following:
  • ID of the story
  • Name/description of the story
  • Importance/Priority of the story
  • Initial estimate (in points or ideal days)
  • How to Demo - a brief description of how the story will be demonstrated to stakeholders.
  • Notes
Of these fields, the "How to Demo" is one near and dear to me. It's basically a narrative around what exactly you would do to verify that the story is working in such a way as to communciate it clearly to the customer.

Perhaps even more critical, though, is that by writing out how they plan to demo a feature, the team is forced to write out their assumptions, which can then be quickly challenged by the customer.

For example, in a toy store application, a story might say "Add games to the catalog". The "How to Demo" might read: "Log in, select the Add Game menu, and enter the details in a form. Verify the information gets stored in the DB".

A customer might then see the estimate as 2 weeks, and say "No, no, I don't care if you enter the information manually in the database, we don't need a form and fancy input screens yet."

This is commonly referred to as an "acceptance test" in XP literature, but is often forgotten by teams just starting out with Agile. This simple tool can greatly improve your communication with the customer, and help avoid misunderstandings.

Henrik goes on to explore many different subjects such as dealing with multiple teams, splitting up stories, etc. He also makes it clear that many of his conclusions are preliminary, since his team is still learning and adapting, and that he might do things differently in a different context.

All in all, a great contribution to the body of Agile knowledge, and a fun read.

For more on agile tools and techniques:
(Tags: , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


Post a Comment

<< Home