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

Thursday, November 02, 2006

Agile Estimating: How long is an ideal day?

About seven years ago, my first attempt at doing an estimate using agile terminology went something like this:

Me: "OK, I estimate this functionality at about 3 ideal weeks of effort"
Boss: "Uh...what is that in calendar time?"
Me: "Well, er, it's complicated, it depends on team velocity and planetary motion"
Boss: "Great, can you tell me by tomorrow?"

After doing some reading and thinking, I decided an ideal week was something like a "man-week", adjusting for daily distractions. For most people I've worked with, this adjustment factor (called a "load factor" in the original XP books...yikes) is somewhere between 0.5 and 0.7.

In fact, some studies suggest that the maximum productive time for most workers is five hours, regardless of how much time they spend in the office. Work that requires intense concentration, like say, software development, is more prone to productivity loss from distractions, phone calls, etc.

In other words, an ideal week for a single developer looks a lot like half of a "man-week". Looked at differently, a developer has a capacity (or velocity) of 0.5 ideal weeks per calendar week, or for a two-week iteration, about one week of ideal effort.

So a team of four developers of roughly equal capability would be able to implement about two ideal weeks worth of estimated effort in an iteration (of 2 weeks).

Another popular method of estimating agile user stories is to use a point system to measure the relative size. By using points, a team can estimate the size of a story relative to other user stories.

A 2-point story is twice as difficult to implement as a one point story, and a 4-point story is twice as hard again.

Personally, I tend to prefer the ideal time units, since it's easier to explain to customers, but I have heard reports that point systems have had good results as well after the initial confusion.

How do you estimate and why?

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

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