Please see topic https://jazz.net/forums/viewtopic.php?t=3062 for the context of my posting. This is the third topic of three.

Q9. As a manager I want to know the best dashboard views to use so that I can determine progress during each Scrum team's sprint.
A9. I recommend view "Current Iteration Plans," which shows each Scrum team's progress bar for the current sprint, the percentage of tasks estimated, work hours done, total work hours, and difference between actual and expected progress against the plan. In the Web UI, select "Iteration Plans" then "Current Iteration Plans."

Q10. As a manager I want to know the best dashboard views to use so that I can determine each Scrum team's progress against their product backlog.
A10. View "Current Iteration Plans" also shows each Scrum team's product backlog for the current release, including the percentage of tasks estimated and total work hours. Note that user stories are estimated in story points and the "Current Iteration Plans" view does not calculate story point totals. Agile teams create high-level estimates in story points at the beginning of a release (and whenever a new story is added to a team's Product Backlog), and detailed task estimates in hours at each sprint planning meeting. I recommend using reports "Story Points," "Storypoints by Iteration," and "Team Velocity" to monitor a Scrum team's progress throughout the release.

Q11. As a manager I want to know the capacity of my team for a release so that I can draw lines in the Product Backlog for the should haves, could haves, and might haves.
A11. Assuming constant-length sprints, a team's high-level capacity in story points is approximately their "Team Velocity" multiplied by the number of sprints in the release. Average velocity allows you to determine the must haves. Doing the same calculation using the team's fastest velocity allows you to determine the could haves. Story points are a "good enough" estimate of a team's capacity at the beginning of a release. Calculating a team's actual capacity in hours assumes all work hours and planned absences are entered in Rational Team Concert. When teams plan sprints in detail, they confirm the accuracy of their high-level story point estimates at the time when they have more (the most?) information about tasks that need to be completed.

Q12. As a manager I want to track statistics on a Scrum team's progress so that I can use historical information to plan future releases.
A12. The key reports are "Burndown," "Sprint Burndown" Is this report any different than the "Burndown" report?], "Story Points," "Storypoints by Iteration," and "Team Velocity." To display a Release Burndown report, choose "Sprint Burndown" and modify its parameters to select all team areas and intervals (sprints) in the release.

Q13. If a team has to work overtime to make up for a task in the sprint taking longer than planned, how is that reported and displayed?
A13. For tasks that take longer than expected, set the "Correction" field to the total number of expected hours. This will likely create a spike in the "Burndown" report. The progress bar also changes to account for the additional hours.

Q14. What does the sprint report show if a story is brought ahead into this sprint after the sprint is already planned?
A14. The "Burndown" report will show a spike representing the additional hours of task work the team accepts in the sprint. The "Story Points" and "Storypoints by Iteration" reports will show the additional story points the team accepts in the sprint.

Paul Sims
IBM WebSphere Commerce