Sprints

We all crave regularity. We want a steady rhythm and a strong downbeat so we know the steps we need to take. This article explains how to give that sense of continuity to your software teams through fixed-length iterations, whatever length that is.

Should teams receive partial credit on nearly finished stories when calculating their sprint velocity? Find out in this video blog from Mike Cohn.

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.

In last month's newsletter I wrote about the idea that everything happens within a sprint. There is no "outside a sprint" during which team members might do things like design, bug fixing, or anything else. In this newsletter I want to share one possible exception to

The biggest flaw in overlapping iterations is that there is never a time (except the end of the project) when all teams are done.

Scrum, like all of the agile processes, is both iterative and incremental. Since these words are used so frequently without definition, let’s define them.

An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. The team then iteratively refines those areas until the product is satisfactory. With each iteration,...