Iteration Summary

The Iteration Summary app helps you understand how an iteration is going, with text-based guidance. Based on the status of work and defects, you'll see shows colored indicators that help your team address problems as they happen.

Iteration Summary

Data displayed

The top section will show basic iteration details:

  • Name
  • Days remaining
  • Total days
  • Iteration state - Planning, Committed, Accepted

Depending on the state of your iteration, multiple data points are displayed with advisory messages.

Accepted work

This section will always be on display, showing the percentage of work with a schedule state of Accepted. Work that counts against this percentage includes:

  • User stories
  • Independent defects (not attached to stories in the iteration)

The bar next to the percentage of accepted work will change colors, depending on the state of the iteration:

  • Grey - Some, all, or no work accepted, during the first half of the iteration.
  • Green - All work accepted, iteration has ended.
  • Yellow - Some or no work accepted, during the second half of the iteration.
  • Red - Some or no work accepted, iteration has ended.

Active defects

This section will only appear if there are open defects attached to user stories in the iteration. The total number of defects that are not in a Closed state will display. This bar next to this section will change colors, depending on the iteration state:

  • Yellow - Any open defects, iteration still active.
  • Red - Open defects remain, iteration has ended.

Defining the first half of an iteration

These status updates rely on the age of the iteration. The rules for defining the first and second half of an iteration are as follows:

  • If the iteration is 10 days or less in length, colors will shift from grey to yellow after 50% of the days have passed.
  • If the iteration is 10 days or more in length, colors will shift from grey to yellow after the fifth day of the iteration. This is because it is much more dangerous to be in the third week of a four week iteration with no accepted work, compared to the third day of a five day iteration.

Additional features

  • Use the Auto Height setting to automatically adjust the vertical space of the app based on the amount of visible data

Coaching Corner: Why Are These Warnings Important?

The following recommendations for each section of the Iteration Summary panel were provided by Ryan Polk, who is a Coach at Rally. Our coaching organization specializes in agile methodology, and helps customers tailor their use of Rally to unique workflows. Please review the following with your scrum teams, to ensure you create effective Definitions of Done and Working Agreements.

More great advice like this is available to Rally customers who would like to further enhance their agile process. Now, it's even easier to set up a quick call, with our new services offering. For a minimal fee, you can schedule a one hour advising session on the phone. For more details, click here.

Why do stories need to be accepted early in the iteration?

Unaccepted stories represent risk. Risk that the story may not be completed by the end of the iteration, and risk that the entire iteration could be thrown into disarray when unacceptable work is discovered. To mitigate this risk, it is advisable to inspect stories regularly and accept approved user stories as soon as they are completed. The proactive management of user story acceptance will allow the team ample time to deliver fully acceptable stories based on their agreed upon definition of done.

Aside from risk, on-time acceptance of stories is important to achieve accurate burndown charts. Completed story points are not reflected in these charts until acceptance. If you do not accept stories as they are completed, your chart will remain flat until the last day of the iteration, rendering it useless to your team and stakeholders.

From a Lean perspective, unaccepted user stories represent Work In Progress (WIP). In lean and agile software development we look to limit WIP by limiting the number of stories concurrently in progress. This limitation applies to stories that are complete yet unaccepted as well. Those stories are considered in progress, because at any point they could be deemed unacceptable and moved out of a completed state. Maintaining WIP limits will smooth out the development team flow by limiting interruptions and context switching, caused by jumping backwards in the iteration.

Why should all defects be closed before a story is accepted?

When creating a Definition of Done for user stories, it is recommended that teams require all defects on those stories be closed before accepting them. Since an accepted story represents a completed slice of functionality, any defects attached to that story represent technical debt and should be resolved during the iteration.

It is good practice to test user stories as soon as they are ready. If additional time is needed to resolve a found defect, the team should consider doing so, before moving on to other stories in the iteration. If the resolution of the defect requires a significant amount of time the team should not release the associated user story, and consider the necessary work as part of the next iteration's estimation. Overall, it is better to deliver a single completed and fully tested story, as opposed to delivering several incomplete and untested stories after an iteration.


Need more help? The CA Agile Central Community is your one-stop shop for self-service and support. To submit feedback or cases to CA Agile Central Support, find answers, and collaborate with others, please join us in the CA Agile Central Community.