The scrum of scrums meeting is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. Imagine a perfectly balanced project comprising seven teams each with seven team members.
A discussion of six attributes that the ideal ScrumMaster should possess.
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.