The selection of a new Scrum team’s ScrumMaster can impact the success or failure of the team's Scrum adoption. Choose the wrong person and the team could face the uphill struggle of trying to become self-organizing while under the thumb of a command-and-control style manager. Choose the right person—matching the skills of the new ScrumMaster with the initial needs of the team—and the team will have an incredible headstart in adopting Scrum.

User stories are a great way to get people talking about requirements. However, there's a reason why we invented the written word: to make sure that nothing we've said is forgotten or misunderstood. This article explains why contracts are a good way to capture not only the user stories themselves but also to spell out what constitutes the successful implementation of each story.

Numbers may not lie, but measurements can sure mislead you. This article explores two myths about metrics and management and offers guidelines for devising project metrics that won't leave you broke and busted.

Many teams try to divide and conquer when it comes to sprint planning, often with disjointed and disappointing results. This article explores why planning, like so many other agile practices, should truly be a team sport.

If the only certain things in life are death and taxes, why do so many teams think that if they plan well enough they're somehow going to add software to that short list? This article deals with the mistakes team make when they try to account for every potential need and how best to plan for those things that users don't even know they want (or don't want).

An academic paper that describes the importance of using more than just the vaguely defined "business value" when prioritizing features.

An experience report presented at XP2006 covering why it is not as simple as telling product owners to "prioritize on business value." This experience report presents additional factors to consider when prioritizing.

Change may be a constant, but it doesn't have to be constant. By following some simple guidelines, you can choose when and if you will allow adjustments to planned work during an iteration.

This tongue-in-cheek article offers humorous insight into the pitfalls of the waterfall process. You'll find yourself laughing at agile experts gone mad. You might even recognize some of your own company's policies taken to an extreme.

A key consideration in adopting an iterative process is selecting how long your iterations will be. Mike Cohn discusses the issues to consider when determining whether your team's iterations should last two weeks, three weeks, or longer.