Often times in iteration planning teams task out the stories, put people's names on the tasks and have them estimate the tasks. Each person gets an understanding of what they're slotted to take on in the iteration and can then determine if it is reasonable to commit to the iteration content. While the names are often "in pencil" and subject to change based on how the iteration goes, there are good reasons not to put them on there at this point.

One common struggle when adopting agile (particularly in large organizations) is that it can be very difficult to get things done within a short iteration (typically two weeks). Often times, people on the team will push for lengthening the iteration to make it easier to fit things in. There are a few reasons why you might want to avoid this.

It has long been accepted that defects are an unavoidable consequence of developing software. Large software projects tend to keep track of these in a defect management tool with the goal being to keep defects tracked there to a reasonable level (sometimes reasonable is defined as loosely as hundreds of defects). But, is an accumulation of defects really unavoidable? And until a team determines how to avoid them, how do defects fit into an agile process?

There are a few different ways that you can define a release. First, you can specify the functionality that needs to be in the release. If you take this approach, the release is done when you complete the functionality. Alternatively, you can specify a date. When you hit that date, the release is done. Generally speaking, you're much better off taking the latter approach.

The Agile Manifesto says "Individuals and interactions over processes and tools". In other words, that people working together is a very valuable thing. Conversation is a very efficient communication mechanism. Collaboration fosters team work, unifying of goals, etc. Processes and tools, if misused, can lead you astray and keep people apart by encouraging handoffs and focusing your attention on things which don't add value. But this doesn't mean that processes and tools aren't beneficial. Just that you need to be thoughtful when you incorporate them such that they don't discourage that which you truly value.

It is a good idea to estimate the size for every story that you take on. Depending on your team, this might be in story points (recommended), ideal days or something else. A team's velocity for an iteration is the sum of the points for the stories completed in that iteration. You can also track how many points you attempted to complete for the iteration. Tracking both of these over time can be very illuminating.

When you have multiple teams working together, there are several ways to handle the resulting dependencies. Each has their trade offs, but I would rank them as follows:

1. Structure the teams so that a single team can solve the problem end to end
2. Do the work within the same iteration
3. Implement the service and then use it
4. Stub out the service and implement it later

I've been attending a web-based course from Alan Shalloway on lean. Here are some of the highlights from the final session (focused on Product Coordination and Release Planning). See this link for the previous session (which contains links to the other sessions as well).

Iteration Planning, if done right, can go quickly and painlessly. The objective of iteration planning is to understand what you're attempting for the next iteration and to plan out just enough that you're confident that you can achieve it.

On April 7th, Scott Bellware gave a presentation at Agile Austin entitled "5 Things I Learned from Lean". Scott had worked on a rewrite project that failed. He looked to lean to identify the issues that led to the failure / how he could prevent similar failures in the future. This presentation was focused on those lessons learned.