Scrum Fundamental: Planning and Iterating

This is my last post, for now, in this series on common issues teams have with fundamental Scrum concepts. Here are a few tips, reminders actually, for planning and iterating.

Make story estimates visible to the Product Owner. Understanding the relative costs of features helps make better trade-offs.

Product Owners reprioritize work not started. Always work on the highest value story and risk reduction stories first.

Plan a second release from the start. This takes the pressure off. “We’ve just got to have feature X!” becomes “ok, we’ll put feature X in the second release and not worry about it now.” You may never do feature X, or release two, but it helps the first release move along unhindered.

If you need to know when you’ll be done, make a build up chart for the release. See Alistair Cockburn’s article on this topic.

Minimize the amount of work in process (WIP). Limit this in two ways: In each iteration, have the whole team work on just a few stories (like, three to six, depending on size). I put some rules of thumb on this in an earlier post. Don’t start work on something that cannot be completed in the iteration. With traditional project management using Gantt charts, you identify and care for the critical path. With agile projects, you limit WIP and increase cross-training, teamwork, team goals and collaboration to care for the critical path.

In addition to limiting the number of stories in the iteration, limit how many stories can be in progress at any one time. Limiting WIP to, say, one-third of the number of stories committed to the iteration might be about right. Then work towards limiting it to just one.

That’s it for now. But there is so much more that can be said. I welcome your own thoughts and lists and links to other relevant information in the comments below.