Data Integrity Dashboards for Agile Health

Document ID : KB000047671
Last Modified Date : 14/02/2018
Show Technical Document Details

Summary

This dashboard is your first stop to help teams keep data in CA AC accurate and encourage healthy agile behaviors. The data integrity dashboard helps you take appropriate action to ensure that you can utilize metrics to help guide teams for continuous improvement.

Issue

Welcome to your Data Integrity Dashboard
This dashboard is your first stop to help teams keep data in CA AC accurate and encourage healthy agile behaviors. The data integrity dashboard helps you take appropriate action to ensure that you can utilize metrics to help guide teams for continuous improvement.
?
What you?ll discover is how all these things are interconnected to your team?s agile progression.

The app used for these dashboard is the Custom List App

Cause

Current Iteration/Release
It?s important to ensure that the current iteration/release for your Team(s) has all the necessary data completed: Planned Velocity, proper Start and End Dates, that it exists in all levels of the hierarchy, and its State..? This allows you to know at a glance if the current iteration/release is over scope, within in the right cadence, and if the team has committed to the scope of work.? Mature Agile teams will keep a percentage of Planned Velocity reserved for spikes or other work and will have committed to the plan prior to even starting the Iteration/release.
?
?User-added image

Old Iterations that are not accepted
Accepting an iteration/release at the end of the iteration is recommended. If not accepted it will cause certain instances of the Iteration/Release dropdown UI component to become unruly as dropdowns that are used for scheduling Stories and some Dependency apps are populated with all Iterations/Releases that aren?t Accepted. Review Iterations listed, mark the Iteration/Release as Accepted by editing the Iteration/Release. Going forward, mark the active Iteration/Release as Committed once the team has finished planning and mark it Accepted during the Closing ritual.

?User-added image

?
Current iteration stories missing estimates and/or owner
If Stories do not have a Plan Estimate, they will not be represented in charts that use Points as the unit of measure (e.g. Iteration Cumulative Flow chart and the Velocity chart). The Story Owner helps the team and others identify who to go to with questions and who will be responsible for Accepting the Story. Review all Stories listed and identify an Owner and determine an Estimate as a team. Going forward, groom Stories prior to Iteration Planning.
?
User-added image
?
Current iteration tasks missing estimates and/or owner
If Tasks do not have an Estimate, they will not be represented in charts that use Hours as the unit of measure (e.g. Iteration Burndown). The Task Owner is the team member responsible for completing the Task. Both of these fields are necessary for load balancing during Iteration Planning on the Team Status page. Review all Tasks listed and identify an Owner and Estimate as a team. Going forward, establish Owners and Estimates for all Tasks during Iteration Planning.
?
User-added image
?
Past iteration stories and tasks missing estimates and/or owner
Looking back for those stories and tasks that are missing Owners and/or Estimates allows for the team to retro on the reasons why this may have not have been entered.? This also allows the team to sense their growing accomplishments in their Agile journey as all data points are entered during the proper ceremonies.

User-added image
?
Completed/Accepted stories with task hours remaining
Accepted or Completed Stories should not have task hours remaining. This will cause confusion as the Task To Do hours indicate there is remaining work to be done on these Stories even though the Stories have been Accepted by the Owner. Review all Stories listed and identify if remaining work exists. If so, mark the Story as In-Progress and move it to the active Iteration or the Backlog. If not, update the Task so that all tasks are Completed.
?
User-added image

?
?
?
User Stories not accepted in previous iterations
Accepting a story within the iteration is considered good practice in scrum. Not accepting stories within an iteration causes risk and overhead and might result in lost work. Review all Stories listed and identify if remaining work exists. If so, mark the Story as In-Progress and move it to the active Iteration or the Backlog. If not, update the Story to an accepted state.
?
User-added image
?
Tasks not completed in previous iterations
Accepting a story within the iteration is considered good practice in scrum. Not accepting stories or completing tasks within an iteration causes risk and overhead and might result in lost work. Review all tasks listed and identify if remaining work exists. If so, move the story to the active Iteration or the Backlog. If not, update the task to completed.

?User-added image
?
Completed stories with non-passing test cases
Why did a story get accepted if not all the test passed; was this documented in the notes or a discussion?? Was it a change to the criteria?? Again, retroing on this type of information helps the team in it?s agile growth.
?
User-added image
?
?
Accepted Defects not marked closed
Closed defects should also be accepted. When a Defect gets marked Closed, a Closed Date gets associated with the Defect. This date is used in certain calculations to determine the length of time a Defect has been opened. Once a Defect gets Accepted, mark it as Fixed (or Closed if appropriate) and at the end of the Iteration, make sure to mark it Closed. You can bulk edit such Defects to make this process easier.
?
User-added image
?
Defects not accepted in previous iterations
Accepting work within the iteration is considered good practice in scrum. Not accepting work within an iteration causes risk and overhead and might result in lost work. Review all Defects listed and identify if remaining work exists. If so, mark the Defect as In-Progress and move it to the active Iteration or the Backlog. If not, update the Defect to an accepted and closed state.
?
User-added image
?
?
?
?