Agile Software Development

The adaptation mechanisms built into the Scrum process allow for many modifications and adjustments in the sprint planning procedure. Different variations work for different teams and environments. Here is one of the variations that I find useful:

Preconditions

Product backlog contains a set of user stories sufficient for at least 2-3 sprints, ideally - for the whole current release and more. The team together with the Product Owner and possibly with some stakeholders went through the top stories 2-3 days earlier. As a result for a sprint or two there are enough reasonably small and well understood top priority product backlog items.

Advertisement:

Scrum is an agile software development process with a high focus on the project management level. It has a concept of a sprint review in the end of the iterations, where the product backlog items taken into sprint (and possibly the whole sprint) are accepted or rejected. It is possible and even recommended to accept or pre-accept some items already during the iteration, but it is not mandatory and is not always possible.

During sprint review Product Owner indeed can reject the content, because the team got him wrong, perceived quality is low, some old features got broken or team simply did not have enough time to finish everything it was hoping to deliver. Then what does the rejection mean? Isn't it a bit too naive to expect the people disappointed by rejection deliver better during the next sprint? Isn't it easier just to add some "fix tasks" to the backlog?

There are not that many people who like micromanagement. No surprise that the fear of day to day micromanagement scares some people off the agile processes. That is not the only way agile processes can look micromanaging. All the agile processes employ the idea of iterative and incremental planning on pretty much every possible level. Scrum Product Owners can change the project priorities every 14-30 days, in Extreme Programming, the usual iteration length is just one week. Naturally the possibility for the rapid shifts in the priorities can make it difficult for the team to design and build a good architecture and work at a full possible speed.

Update: Link to XLS fixed. Kudos to Jukka Laurila

Some teams using Scrum and XP tend to have special Q&A iterations every several iterations and/or before the release. While it might be ok, during the transition to the agile processes, as a rule of thumb having Q&A sprints is a good indication of the problems with the definition of "done". The main point of iterative development is to have a "potentially shippable" product at the end of iteration. Planning for Q&A sprints essentially means that at the end of the iteration, team does not plan to have a potentially shippable product.

Update on 09 Oct 2007: "See Also" section added

Bas Vodde collected and published examples and templates of the Scrum product and Sprint backlogs. Most of them are in MS Excel format. Some (XLS) include a lot of comments, some (XLS) are very colourful. Check them out, Excel can really cover most of the needs of the archived backlog tracking.

See Also

• Simple Product Backlog Example
• Simple Sprint Backlog Example