The Product Progress Report shows the status of releases across products selected for inclusion in the report. When a product is selected to appear in the Product Progress Report, the progress against the work allocated to the release is superimposed on a chronological representation of releases (as indicated by the release begin and end dates).

Work progress is measured in "Product Backlog Effort units". For example, a progress bar that shows "217/274 (79%)" means that of 274 Product Backlog effort units currently scheduled for inclusion in the release, 217 have been marked "Done". This means that 79% of the currently scheduled work has been completed by the team.

The work progress is then superimposed on a chronological schedule. If the release is currently active (i.e., today's date is between the begin and end dates associated with the release) a red line will indicate "Today". Thus the work progress can be seen in clear relation to the proposed schedule.

This report updates itself each time there is a change to the system. In Scrum, changes are accepted as a normal occurrence in project work. If the release dates, total backlog effort points or number of points marked "Done" change, then the Product Progress Report will mirror the changes automatically.

A release must have an associated beginning and ending date to show up in the Product Progress Report. Two date fields are supplied for creating a Product Progress Report: a start date and an end date.

Releases occurring in this range are included in the report. The release doesn't have to be entirely contained within the dates; any release that overlaps the date range selected will be included in the report.

In ScrumWorks Pro, begin and end dates associated with releases imply a schedule. The Warning Level lets users customize how releases that are behind schedule appear. When a release is behind schedule, the color of the progress bar can be either yellow or red, and the Warning Level dictates whether red or yellow is displayed. The Warning Level is the threshold above which ScrumWorks Pro displays a red bar to indicate that the release is behind schedule by a percentage greater than or equal to the Warning Level value. For example, if the Warning Level is set to 10%, the progress bar for the release will be yellow if the project is only 5% behind schedule but red if the project is 11% behind schedule.

Required Permissions: View Reports

The Product Progress Report is accessed as a PDF file; however, a preview is available before the final PDF is published. To preview a report:

1. In the left pane, select all Products for inclusion in the report.
2. Then adjust the Date and Warning Level settings as desired.
3. Click the Generate button to see a preview of the Product Progress Report.

Once satisfied with the preview, click the Launch button to generate the actual report in PDF format. Take note of the URL associated to the report. The URL is accessible from outside of ScrumWorks Pro and is a convenient way to reference the report at a later time or to share the report via email. For convenience, the Report URL is accessible directly without the need to log into ScrumWorks Pro. As a result, be sure to keep the Report URL private if privacy is a concern.

Required Permissions: View Reports

Date Range

Display Interval

User Availability

Enter the average number of hours users are available per display interval. This figure will be used for all users in the system. If individual figures are desired for particular users, this figure may be changed in the exported Microsoft Excel file.

Required Permissions: Program or Product Administrator

Team member workload is calculated as follows:

The estimates of all tasks claimed per user among all Sprints occurring during the display interval are summed. Task estimate totals per Sprint are then divided by the number of working days in the Sprint to give a daily average load for that Sprint. The average daily load per Sprint is then multiplied by the number of working days that Sprint is included in the selected interval. Where multiple Sprints are included, multiple daily averages are summed to result in the total workload for the selected interval.

When a user claims a new task, the task estimate is added to the workload for the interval. The allocation is updated when the report is refreshed. Note, however, that this additional task’s estimate has been added to the total workload across the number of days in the selected display interval. For this reason, the report provides only a general picture of workload over the course of the interval, not a precise day-to-day snapshot of any given Team member’s allocation.

1. User availability is listed as a total for each user in an "Hours Available" column. This number is the same as the figure entered in the report specification interface.
2. The dates for each display interval in the report are listed in the "Load" and "Allocated" columns for every interval.

This variation of the release burndown chart features a Sprint-by-Sprint picture of Release progress. The x-axis increments are therefore sprints rather than chronology. The chart may be filtered by Theme.

Here is an example of the Release Burndown by Sprint:

Each bar represents the amount of product backlog remaining on the first day of each Sprint. For each selected release, the product backlog consists of all uncommitted backlog items for that release and all committed backlog items in sprints in that release.

Each backlog item maintains its own effort history, recording entries as the backlog item is re-estimated over time. This historical view of each backlog item is used to calculate the total effort remaining on the first day of each sprint.

Backlog items committed to sprints can be marked "Done". By marking an item "Done" the release burndown will lower the bar height for the corresponding sprint equal to the backlog item's effort. Bar heights can also be reduced if backlog items are re-estimated at a lower effort value. The bars increase in height when new backlog items are added or existing backlog items are re-estimated at an increase.

For multi-team Products, the data for sprints ending within one week of each other are merged into one bar on the chart. It is not possible to have a separate release burndowns for each team contributing to a release since all teams are working on a common pool of backlog items.

Required Permissions: View Reports

This chart distinguishes between work completed and work added/removed. The Velocity Trendline shows the rate at which work is completed. The Work Added/Removed Trendline shows the trend of commitment change and backlog re-estimation. A new baseline is drawn as a result of work added or removed through the last completed sprint. If work is completed faster than it is added, ScrumWorks Pro can estimate how many sprints it will take to complete the product. Release completion can be forecasted by extrapolating these two trendlines to their intersection.

Here is an example of the Release Forecast Report:

This chart shows that if the current trends continue, release completion is forecast in 1-5 sprints.

The bar high positions on this chart are plotted by subtracting the amount of backlog burned during the prior Sprint. Each subsequent Sprint bar high position will either go down or stay flat, but never go up.

The lower portions extending below the previous Sprint's low position denote new backlog items added or additional effort as a result of re-estimation. The low bar position can also go up from the previous sprint. This happens when the total effort decreases, either through the removal of product backlog or a decrease caused by re-estimation of existing backlog items.

Data for sprints ending within one week of each other are merged into one bar. This is especially useful when multiple teams are working from the same product backlog. It helps give a more accurate (and less crowded) picture of the work being done.

Options for Release Forecast Report

In the Release Forecast Options tab, two Velocity Trendlines and various Velocity Projections are offered. Either trendline may be selected and specified in combination with any of the available Velocity Projections, offering a highly customizable chart. When the option for Completion Forecasts is checked, any specified trendlines and projections that will intersect in a reasonable amount of time with the Work Added/Removed Trendline will be extended to those points, and the chart will expand in scale to display the intersections. If no specified trendlines and projections will intersect with the Work Added/Removed Trendline, no completion forecast is possible and will not be displayed.

Required Permissions: View Reports

1. Effort for all uncommitted backlog items in the release
2. Effort for committed backlog items in sprints within the release

Select the Build Chart button to re-display the chart using the selected releases.

Required Permissions: View Reports

1. In the Themes subsection of the Releases & Themes tab in any of these three reports, click the checkbox for "Filter chart by Themes"
2. Clicking "Edit Filter" generates a Themes Filter dialog offering checkboxes for all Themes that exist in the Product. By default, the filter "for all checked Themes" option is selected, which will include in the chart only those backlog items that are marked with each and every Theme selected in the list below. Selecting the "for any checked Themes" option charts backlog items that contain any one of the Themes selected in the list. Selecting the "exclude checked Themes" option will include all backlog items except those marked with the Themes selected.
3. Check the Themes appropriate for your filter selection from the list below. Note the checkbox "(no Theme assignment)" for Backlog Items that do not have a Theme assignment. Checking this box acts the same as the checkboxes for Themes, either including or excluding from the chart Backlog Items with no Theme assignment depending on the filter action chosen above.

Select the Build Chart button to re-display the chart using the selected Themes.

Required Permissions: View Reports

To show that work has been completed use the backlog editor to set individual backlog items as done by picking a status with a "Done" status type. The release burndown chart uses this information to draw the height of each of the sprint bars and to calculate the velocity.

Required Permissions: Mark Product Backlog Item as Done

The current release effort remaining on the first day of each sprint is the value used to draw the height of each of the sprint bars. Sometimes a backlog item will be created after the start date of the sprint for which this backlog item belongs. You can adjust the creation date of this backlog item so that it impacts the current sprint, backdating the backlog item. Edit the first entry in the backlog item's estimate history to the first day of the Sprint you want it to impact. This allows for a more precise graphical representation within the release burndown.

Please see Edit Product Backlog Item Estimate History for more details on editing backlog item estimate history.

Required Permissions: "Product Backlog Items" > "Edit Historical Estimates"

This report summarizes changes to the outstanding backlog including work completed this sprint, work added/removed from the release backlog, and how re-estimation affected the release backlog.

Required Permissions: View Reports

1. Click "Reports" -> "Sprint Change Report"
2. Open the Release Burndown by Sprint Report and select the "Sprint Change Report" tab

This presents you with a clickable chart. Single clicking a bar selects the sprint and gives you a URL that contains your report. Double clicking the bar opens your report.

Required Permissions: View Reports

Limited in scope to a specific Product, the Release Burndown by Date Report shows the total outstanding backlog effort remaining on each day of the Release. In contrast to charts updated each Sprint, this graph provides a detailed view of Release changes, updated daily. The y-axis therefore represents outstanding backlog effort for selected Release(s) and the x-axis is chronological by day. Any increases in backlog effort (e.g., estimation, new backlog items added) will trend the graph upward, while any reductions (e.g., items moved out of the Release, finished backlog items marked "Done", deleted backlog items) will lower the point corresponding to the date of the change. Changes to a release's total backlog effort are reflected in the graph immediately.

A trendline based on the "best fit" algorithm is included to help forecast the likelihood of timely completion. When possible, the graph's x-axis will adjust to show the x-intercept of the extrapolated trendline. To fine tune forecast projections, users may manually override the starting date of the trendline. Any date before this manually entered date will be ignored in calculating a trendline.

More than one Release can be included in the graph if desirable. The date range of the graph is automatically inferred from the selected Release(s). For releases with designated start and end dates, the start date is taken from the Release start date, while the end date depends on trendline extrapolation, if any. In cases where one or more selected Releases do not have start and end dates defined, the graph's start date will be the first day any activity was detected for any of the selected releases. Users can zoom in on a particular segment of the graph by selecting the area with the mouse.

In cases where only Releases with dates are selected, the report will darken the background of any date ranges before the first starting date and after the last Release end date. In this way, the start and end dates of the Release cycle(s) are in focus while examining the report. If any selected Release does not have a start and end date specified, the report will not feature background darkening as the date scope of the selected Release(s) is uncertain.

Here is an example of the Release Burndown by Date report:

1. With a Product window in focus, go to the Reports menu and select "Release Burndown by Date"
2. A dialog appears with a list of all releases. Select a Product release, or a Program Release. This graph has Product scope, so even if a Program release is selected, the output will be limited to the current Product's involvement in the selected release.
3. Click "Build Chart" to view the data selected.

At the Program scope, the Release Burndown Graph shows the total outstanding backlog effort remaining on each day of the Release for all Products contributing to the release. The Y-axis represents outstanding backlog effort for selected Release(s) and the x-axis is chronological by day.

Each Product contributing to the release is represented by its own data and trend lines, coordinated by color. For each Product, any increases in backlog effort (e.g., estimation, new backlog items added) will trend the lines upward, while any reductions (e.g., items moved out of the Release, finished backlog items marked "Done", deleted backlog items) will lower the point corresponding to the date of the change. Changes to a release's backlog effort are reflected in the graph immediately.

A trendline based on the "best fit" algorithm is included for each Product to help forecast the likelihood of its timely completion. When possible, the graph's x-axis will adjust to show the x-intercept of all Products' the extrapolated trendlines. To fine tune forecast projections, users may manually override starting date of the trendline. Any date before this manually entered date will be ignored in calculating a trendline.

More than one Release can be included in the graph if desirable. The date range of the graph is automatically inferred from the selected Release(s). For releases with designated start and end dates, the start date is taken from the Release start date, while the end date depends on trendline extrapolation, if any. In cases where one or more selected Releases do not have start and end dates defined, the graph's start date will be the first day any activity was detected for any of the selected releases. Users can zoom in on a particular segment of the graph by selecting the area with the mouse.

In cases where only Releases with dates are selected, the report will darken the background of any date ranges before the first starting date and after the last Release end date. In this way, the start and end dates of the Release cycle(s) are in focus while examining the report. If any selected Release does not have a start and end date specified, the report will not feature background darkening as the date scope of the selected Release(s) is uncertain.

1. With a Program window in focus, go to the Reports menu and select "Release Burndown by Date"
2. A dialog appears with a list of all releases for the Program. Because This graph is Program-wide in scope, only Program Releases are listed, but all Products contributing Backlog Items to the releases selected will be represented in the graph.
3. Click "Build Chart" to view the data selected.

The Product Epic Progress report is run from within an open product window. It can be run on a product release, or a program release toward which the product is contributing. Focused on the selected release, it shows the progress of the backlog items in all or a subset of epics in three states: Done, In Progress, or Remaining. "Done" includes backlog items with a "Done" status type; "In Progress" includes backlog items with an "In Progress" status type; Remaining" includes backlog items with a "Not Started" status type

Here is an example of the Epic Progress Report:

1. With a product window in focus, go to the Reports menu and select "Epic Progress Report"
2. A dialog appears offering a dropdown to select a release. Select a product release, or a program release.
3. Below the release selector, a checklist populates with all epics defined for that release. For program releases, only those epics added to the release from within the product will appear. By default, all epics and uncategorized backlog items are selected.
4. Check all epics you wish to include in the chart, and uncheck those you wish to exclude from representation. The "Uncategorized"" selection encompasses any backlog items scheduled for the release but not included in any epic defined for the Release.
5. Click "Build Chart" to view the data selected.

In the resulting chart, each bar represents an individual Epic. The height of each bar represents the total backlog effort defined for the Epic to date. This value is denoted above each bar.

If a budget is specified for the epic, it is represented as a red line and its value is above each bar.

Required Permissions: View reports

1. With a program window in focus, go to the Reports menu and select "Program Epic Progress Report"
2. A dialog appears offering a dropdown to select a release.
3. Below the release selector, a checklist populates with all epics defined for that release. By default, all epics and uncategorized backlog items are selected.
4. Check all epics you wish to include in the chart, and uncheck those you wish to exclude from representation. "Uncategorized" encompasses any backlog items scheduled for the Program Release that are not part of any program epic, including those backlog items that are part of product-only epics.
5. Click "Build Chart" to view the data selected.

In the resulting chart, each bar represents an individual epic. The height of each bar represents the total backlog effort defined for the epic to date across all products in the program. This value is denoted above each bar.

Required Permissions: Program Viewer

When Timesheets are enabled, the report may be generated from two places in an open Product window.

From the Reports main menu:

1. Select "Task Estimates vs. Actuals Report".
2. In the resultant dialog, Specify a Team and Sprint on which to run the report.
3. Clicking "Ok" generates a spreadsheet in Microsoft Excel format.

1. From the selection dropdowns at top of the frame, select the Team and Sprint on which to run the report.
2. Click the "Estimates vs. Actuals" button to the right of the dropdowns to generate the report.

Each time the report is generated, a spreadsheet file in Microsoft Excel format is generated with a name in the following format:

"Task Actuals for [Product name] [Team name] [Sprint start date - Sprint end date].xls"

For every Task in the specified Sprint, the following items are listed in the report:

• Task Title
• Product Backlog Item Title
• User Name
• Hours Spent
• Original Estimate
• Current Estimate
• Variance %
• Task Status

Backlog Items and Tasks are listed in the report in the same order in which they appear in the Timesheet view of the Sprint Detail frame.

Note: In cases where a Task has been carried over from a Sprint prior to the Sprint on which the report is run, the listed hours spent per user will be the hours spent among all Sprints in which the Task remained undone.

You can change the amount of data shown by selecting the time period at the top of the window. By default, the changes made in the last one day are shown. The maximum amount of data that can be shown is 60 hours or 60 days.

Note that for large date ranges it may take a long time to retrieve and display the data.

• Created Backlog Items
• Deleted Backlog Items
• Changes to Backlog Items:
  • Title
  • Description
  • Estimate
  • Estimate History
  • Business Weight
  • Status
  • Release
  • Sprint
  • Priority
  • Themes
  • Attachments
• Date and time the change was made
• User who made the change

• Created Tasks
• Deleted Tasks
• Changes to Tasks:
  • Title
  • Description
  • Estimate
  • Estimate History
  • Status
  • Backlog Item
  • Priority
• Date and time the change was made
• User who made the change

The default sort order is reverse chronological. The latest changes are at the top of the Change Log.

The Change Log can be sorted by "Key", "Title", "Date/Time", or "Username" (the user who effected the change). Note, the "Event" column is not sortable because change log entries may span multiple event types (e.g., description and title). To sort by multiple columns, hold the control key and click the second column header.