Iteration Summary

The Iteration Summary app allows you to see a simple overview of team progress against an iteration. Based on the status of work, defects, and test cases, you’ll be able to see colored indicators that help address problems as they arise.  Source code is available: Iteration Summary source code

Iteration Summary

Data Displayed

The top section shows basic iteration details:

  • Name
  • Days Remaining
  • Total days
  • Iteration state (Planning, Committed, Accepted)

Depending on the state of your iteration, up to three sections display with advisory messages.

Accepted Work

Accepted work total reflects all items directly scheduled into the iteration. 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)
  • Defect suites
  • Test sets

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.

Note: You must have points entered into the Plan Estimate field of scheduled items in your iteration for the percentage of accepted work to display.

Active Defects

Active Defects displays defects that are associated to user stories assigned to the iteration, but are not directly scheduled into the iteration. This section will only display if there are open defects attached to user stories in the iteration.

Note: The intent of this app is to display defects associated to stories that are not being counted in the points for the iteration. This ensures that work is not missed. We don’t recommend accepting stories with associated defects prior to fixing defects.

The total number of defects that are not in a Closed state 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.

Tests Passing

This section displays if test case results exist in the iteration for tests attached to a user story or test set. If there are associated test cases, but no results, this section will not display. The section will be colored depending on the state of the results and iteration:

  • Grey: Some tests passing during first half of iteration.
  • Green: All tests passing, any time.
  • Yellow: No tests passing during first half of iteration, or some tests passing during second half.
  • Red: Some or no tests passing, iteration has ended.

Define the First Half of an Iteration

Many of 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.

Coaching Corner: Why Are These Warnings Important?

Our coaching organization specializes in agile methodology and helps customers tailor their use of CA Agile Central 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 CA Agile Central customers who would like to further enhance their agile process. For a minimal fee, you can schedule a one hour advising session on the phone. Learn more.

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 that the entire iteration could be in trouble when unacceptable work is discovered. To mitigate this risk, 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 enough 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, teams try to limit WIP by limiting the number of stories concurrently in progress. This limitation applies to stories that are complete but still unaccepted. 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 help the development team flow by limiting interruptions and context switching.

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 starting 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.

Why Should All Tests Pass in an Iteration?

In addition to acceptance criteria , test cases represent the overall quality and acceptably of a completed user story or iteration. You can create many types of tests: acceptance, performance, regression, functional, usability, and user interface. All of these types of testing are highly valuable in defining Done for any agile development team. As your team integrates these different tests into its daily routine, it becomes increasingly important that all tests are passing before the end of the iteration. In addition, as many tests as possible should be passing when each story is completed as part of the acceptance process.

As you get closer to the end of an iteration, the fewer tests you have completed, the higher risk you have that your commitments will not be met. Incomplete tests represent the risk of hidden defects that will then lead to technical debt, and possibly disrupt future iterations.


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.