About this report
With the Work in Progress by Step report, you can track how much work is in process for a given PI(s), organized by process flow. The purpose of the Work in Progress by Step 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 State View button to change to the other report version, Work in Progress by State. This report has two versions:
- 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.
- 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).
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 open a menu to move it around the map to different columns, or view its Details panel. Click a work item to highlight its relationship with the other work items on the page. Hover over an item to 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 from the past 30 days. Switch on the Stats toggle in the upper-right corner of the page. Note: Statistics do not display for themes.
- Efficiency: Shows a percentage of efficiency across all steps. When you create process steps, you enter the average amount of time you believe it takes for a work item to move through that step in the Efficiency (Hours in Step) field. This calculation combines that value from all process steps, and divides the total by the actual time all work items spent in all process steps.
Example: A process flow for stories contains 3 process steps. The steps have Efficiency (Hours in Step) values of 6 hours, 18 hours, and 12 hours, respectively.
During the past 30 days, 3 stories were assigned to steps in the process flow. Combined, the stories spent 120 hours across the steps. To calculate efficiency:
(((3 stories * 6 hours Step 1) + (3 stories * 18 hours Step 2) + (3 stories * 12 hours Step 3)) / (120 hours time spent)) * 100 = 90% Efficiency
- Throughput: Count of work items that have moved into the final step in the last 30 days
- Cycle Time: Average number of days it takes work items (within the last 30 days) to move from the process step mapped to the In-Progress default state to a process step mapped to the Accepted default state.
- 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.
- Features can exist and be tied to an epic and PI.
- Stories can exist and be tied to a feature and PI.
- Value streams must be created to use the Value Stream view.
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.