About this report
With the Work in Progress by State report, you can track how much work is in progress for a given PI(s). The purpose of the Work in Progress by State report is to enable users to view and report on work in progress during any given PI. When too many items are worked on simultaneously, quality suffers, the system bottlenecks, and throughput ultimately suffers. Release train engineers can benefit from reviewing this report every two weeks/at the sprint boundaries.
Data displayed on the page is built bottom-up, starting with stories that are associated with the program and PI selected in the Configuration bar and then displaying parent items. This method may result in the display of parent work items or work item counts that do not match the selections made in the Configuration bar. All themes, epics, capabilities, features, and stories are organized by swim lanes; the selected process flows make up the swim lanes in this report.
Use the Step View button to change to the other report version, Work in Progress by Step. This report has two versions:
- Work in Progress by State: The columns within each swim lane represent the default system-defined statuses for each work item (for example, epic statuses include Not Started, In-Progress, and Accepted).
- Work in Progress by Step: The columns within each swim lane represent the user-defined process flow steps for each work item; this requires the creation of a process flow.
This report can be filtered by PI, program, team, and release vehicle through the Configuration bar and page-level filters. Use the View dropdown menu inside of Extra Configs to select the look of each work item icon.
View the legend/key to see what different letters and signs represent. Also, you can show or hide themes, epics, capabilities, features, and stories through the toggles found in the Extra Configs menu.
Right-click any work item to move it around the map to different columns. Click a work item to view its Details panel. Hover over any work item on the page to highlight its relationship with the other work items on the page, and display brief information about the item with an explanation of text coloration.
Work items marked as minimally marketable are shown with an exclamation point.
At the top of each swim lane, you can view their statistics—percent in progress and percent done. For stories and features, in progress statistics count work items that are in the In-Progress, Dev Complete, and Test Complete states.
With Lean Metrics, you can view the key metrics for Work in Progress over the span of the PI—just click the Lean Metrics button in the upper-right of the page. From the Level dropdown menu, you can select a work item type: epics, capabilities, features, or stories. The Team field displays your selection made on the main page and filters data accordingly. The following lean metric graphs display:
Work in Progress: Line graph showing the number of items in progress during the defined time period.
Cumulative Flow: Stacked line graph showing the number of items in an In Progress state, layered against the number of items in an Accepted state during the defined time period.
Avg Lead Time: Line graph displaying the history of the average time, in days, it takes for work items in the PI to be accepted. Each day, a snapshot is taken from all accepted items to draw the line. A work item’s lead time is calculated as the time that passes between the date it is created, and the date it is moved to an Accepted state, plus 1 day.
Example: An epic is created on July 7th, and marked as Accepted on July 9th:
July 9 - July 7 = 2 days +1 = 3 day Lead Time.
On July 9th, two other epics have an Accepted state. Their lead times are 2 days and 5 days. To calculate the average for July 9:
(3 days + 2 days + 5 days) / 3 epics = 3.33 day Avg Lead Time
Avg Cycle Time: Line graph showing the history of the average difference, in days, between the date the work items went into the In -Progress state and the date they were moved to an Accepted state, plus 1 day.
Example: An epic is created on July 7th, marked In-Progress on July 8th, and marked as Accepted on July 9th.
July 9 - July 8 = 1 day +1 = 2 day Cycle Time.
On July 9th, two other epics have an Accepted state. Their cycle times are 2 days and 7 days. To calculate the average for July 9:
(2 days + 2 days + 7 days) / 3 epics = 3.66 day Avg Cycle Time
- PI must exist in the system and be tied to a program.
- Themes can exist and be tied to a PI.
- Epics can exist and be tied to a theme and PI.
- Capabilities can exist and be tied to an epic and PI.
- Features can exist and be tied to an epic or capability and PI.
- Stories can exist and be tied to a feature and PI.
How are report values calculated?
No actual calculations/algorithms are used in the report. All status information is pulled from the corresponding work item page/panel. For example, epic statuses are pulled from the Epics page.
How to interpret this report
The ideal dashboard has very little lag between story and feature percent in process. It is not unusual for epics to lag behind even further, because epics span PIs. Pay particular attention to features, to make sure they are not trailing the stories in process; when feature process is too far behind story process, it indicates a prioritization problem for your stories--most likely working on stories for too many features at once. Minimizing the feature work in process allows you to finish individual features before moving on to more stories. In Jira Align, in the Backlog module, you can the Rank Stories by Features option to get a baseline prioritization for stories.