Rhythms as Agile Diagnostics

review should be done at the end of every iteration. In reality we are not all so lucky to have a real customer review every iteration. In many cases we fall back to our own iteration reviews and fool ourselves into thinking that this is a true customer review . It is not. A customer review must involve a customer.

What are healthy ranges for the customer review cycle ? Of course ‘it depends' on the particular project and context. However, we have found that anywhere from one to three months is healthy. We start to feel uneasy at the later stages of this boundary. When a customer review cycle is too long then there is a danger that the software being built will not address the real problems of the customer. The solution to this problem is to have more frequent customer reviews .

Stories, Functional Tests, and the Burn-down Chart
User stories are the basic unit of functionality and are used to create functional tests . A burn-down chart shows the stories that have been successfully completed and tested and those that are still remaining to be developed.

There are several characteristics that are to be expected in a healthy agile process:

• User stories should be built within one Iteration.
• User stories should describe business functionality, not technical requirements.
• The burn-down chart should be steadily decreasing.

When a user story spans more than one iteration this indicates a problem. Writing smaller user stories is a possible solution to this particular problem and is discussed in the lesson's learned paper Recognizing and Responding to "Bad Smells" in Extreme Programming .

If the burn-down chart oscillates and does not steadily decrease then another set of problems may be present. When stories are based on technical issues instead of functional requirements then as the design of the software evolves new technical stories are created. This will force the burn-down chart to oscillate and the measure of true progress is skewed as shown in Figure 2. Ron Jeffries discusses a metric called Running Functional Tests in A Metric Leading To Agility which is very related to the burn-down chart.

Ken Schwaber and Mike Beedle describe several Scrum Signatures in Agile Software Development With Scrum which are common occurrences to different teams. They recommend that the Scrum Master ought to be aware of the team's signature and take a closer look upon deviation from their typical signature.

IterationSo what is a healthy iteration length? An i teration should be as short as possible while allowing a useful amount of function to be created, tested, and delivered. Iterations should be long enough to produce useful business functionality. Iterations allow the team to manage complexity. We have worked teams that were very successful with iterations of one to four weeks long.

An iteration may be too short if the stories or use case scenarios built have no useful value to the customer and are only ‘pieces' on the way to completion. This means that real story length has crossed the boundary of an iteration. An iteration may also be too short if it is exceedingly difficult to ‘quarter the chicken' (the chicken being a user story) .

Nevertheless an iteration that is too long may point to a different set of problems.

• Stories may become epics with too much functionality. Although the lengthy stories are the problem, it sometimes helps to reduce the iteration length to force stories of smaller size.
• Feedback cycles, which ultimately correspond to an iteration length, are longer. For example, a four week iteration means that we