ChatGPT DEVChatGPT DEV

PractiProject

Capacity Planning and Tracking

Once the Teams are configured properly and assigned to sprints, you can start examining the capacity planning for each team on your board.

Planning and tracking are viewed in the top tab named Planning & Tracking. It gives you the planning and tracking capabilities you always wanted - all from the same screen.

The tab is divided into two areas, the left side is a list of individual project issues you want to view, while the right side panel renders the planing and tracking status and data. Planning and tracking are sprint focused, so first you need to select the sprint under consideration. This can be the current sprint, a future sprint that has not started yet, or the project backlog.

 

image-20240219-232639.png

Sprint Issues

When you select a sprint, you see the following information in the issue panel:

  • Sprint name

  • Number of displayed issues

  • Sprint start and end date and time

  • List of issues

image-20240219-232925.png

The number of issues refer to the number of issues actually displayed. By default, this is the total number of sprint issues. When the list is filtered (see below), it is the number of the filter resulted issues. For each issue, the type, priority, key, summary, epic, sprint, assignee, status and estimate are displayed, similarly to how they appear in the Jira backlog.

When you click on an issue key, the issue details screen is displayed in a new browser tab.

The Estimate field is based on your Jira board settings (Board settingsEstimationEstimation Statistic). The available estimation options supported are: Story Points or Original Time Estimate. Accordingly, the issue display shows the Estimate column in points or time units, respectively. The planning and tracking is then done with those units, and capacities are taken from the respective values as you defined in the Team configuration tab.

Importantly, as part of your planning refinement process, you can:

  • Move issues from the presented sprint to a different one or to the backlog, by selecting the target sprint for an issue.

  • Change the issue assignee

  • Update issue estimation

All of these, from within this same screen!

Issue Filtering

You can filter the list of sprint issues, in order to focus on a relevant subset. Thus, you can choose to display issues the selected team for analysis. The team is selected in the Planning & tracking team field.

In this filter the issue counter shows the number of issues for the selected team, and those issues are displayed in the issue list. You can also select to show issues for an assignee, in which case you can select the assignee of interest.

Issue Grouping

By default the list of issues has no grouping. The Group by: field allows you to view issues groups by epic, issues type, priority and roles. Issues that don’t belong to a selected category (for example when no role is applicable for them) appear under a Not grouped section.

Note that for each group section the total estimation is displayed.

Planning/Tracking Panel

As mentioned above, on the right of the display you can see the Planning/Tracking panel for the sprint, with statistics for the selected Team. If the sprint has a team already set, then a Team field will show it. If you defined multiple teams, you can select the one to examine, using the Planing & tracking team dropdown. If you wish, you can select an individual team member and display only their sprint assigned issues.

The panel displays the total planned work for a selected Sprint-Team assignment, at the right side of the screen. Thus you can observe different views of original work estimation compared to resource time assignment in the team (Potential Capacity vs. Planned Work) .

 

Note: If there is not team defined for the sprint, the left panel is shown empty, and displays a reminder that a sprint team needs to be defined first.

 

  • Team Planned Work - At the top of the section you can see the total planned work of the team you selected. That is, all team members combined planned work compared to the total team potential capacity. The color of the bar indicates whether the planned work amount is less (green), 90-100% (yellow), or excessive (red) compared to team capacity.

 

 

  • Roles Planned Work - planned work overview for each Role in the Team, compared to the calculated potential capacity of each Role for the specific sprint (as defined in the Team Configuration, by total potential capacity of team members set to Role).

  • Team Members Planned Work - planned work per each of the team’s assigned members, for the specific sprint, compared to the team member potential capacity as configured in the team.

The values displayed in the Panel view, are updated at 20 seconds refresh intervals.

Planning Panel View Modes

The planning panel view allows to switch between three modes, each affecting the context of what is displayed in the panel view areas (as described above). To switch between modes, choose the desired one from the Mode: drop-down list in the top left of the view panel.

The modes include:

  • Capacity (hours) - Show planned work calculations based on hours estimations (if hours estimations in use).

  • Capacity (story points) - Show planned work calculations based on story points estimations (if story points estimations in use).

  • Tracking - Amount of planned work compared to the logged work by the team-sprint assigned resources (Planned Work vs. Actual Work). The calculation base used when in Tracking mode depends on the estimation method set for the Board (see above).

 

Sprint Planning

Planned work capacity is calculated based on the issues Time Remaining field values ( not Original Estimate value), giving the sprint planner a truer view of the actual work effort that is planned. Once a sprint starts, planned work values are locked. Any updates to the sprint's tasks Time Remaining field values (such as with log work), do not affect Planned Work values recorded when the sprint started.
Tracking actual work is calculated based on the work logged as completed in the sprint by a team member assigned to it, so for this to be accurate it is crucial that team members update their progress through the use of 'log work'.

Calculation Options

In the view panel there are additional options to select the issues for which estimation and logged work values, the planned work and actual work calculated values are done and displayed, To change between options, choose the wanted one from the top left drop-down list in the view panel (located above the modes drop-down).

 

  • Tasks - calculate only values of issues of types such as tasks, bugs and other issue types in that same level.

  • Tasks + Sub-tasks - calculate all the above elements and their sub-tasks (the original estimation given in the sub-tasks will be addressed and populated).

  • Sub-tasks - calculate only sub-tasks (the original estimation given in the sub-tasks will be addressed and populated).

  • Smart Calculation - Tasks + Sub-tasks, however, if for sub-tasks having original estimate, parent task values are not calculated.

Sprint Tracking

The Tracking mode is available for the current active sprint (it is not relevant for future sprints; for past sprint you can observe the actual achievements in the app reports). Tracking allows you to observe how the progress of current active sprint compared to the work planned for it, before it was started. Therefore, the tracking mode freezes the estimated work just as the print was launched as the reference for the sprint planning goal. The app ignores, therefore, “estimation” changes that were made in the active sprint after it was launched. This ensure honest progress report evaluation compared to the original planning goal.

Note - you are of course able to change estimations of time or story points after the sprint has started. The modified values will appear in the Estimate issue field in the Planning % tracking tab. However, since the app calculation is based on the original estimate, this may appear as discrepancy between the issue list and the planning chart.

Tracking shows progress for the selected sprint team, for roles, and for individual team members.

Tracking progress for time based effort

When tracking progress of the time-effort based active sprint, the app freezes the planning goals as the time estimation of the various issues. If an issue also has remaining time value, this parameter is used as the work estimation entering into the sprint. The remaining time value is also displayed for the Estimate field in the issue list.

For every entity (sprint team, role and individuals) tracking shows color coded Actual vs. Expected.

The Actual value of work completed is calculated by the sum of Time tracking hours logged in all relevant issues (for team, role or individual) since the sprint launch.

The Expected value is based on the days passed since the sprint was launched. It sums the working hours defined for the participants based on the sprint-team definitions. A ticker in the bar chart shows where this value is expected to be.

If the progress, compared to the expectation is too low, it is colored red. If it’s close (80% and above) it is colored yellow. If it meets or exceeds expectation it is green.

 

Tracking progress for story points

Tracking progress of the story point based active sprint, freezes the planning goals when the sprint is launched. .

The Actual value of work completed is calculated by the sum of story points belonging to completed* issues (for team, role or individual) since the sprint launch.

The Expected value is based on the days passed since the sprint was launched. It sums the daily points defined for the participants based on the sprint-team definitions. The ticker shows where this value is expected to be.

 

* By default the definition of issue completion is a Done status. Depending on your organization policy and Jira setup, the app supports other definitions including the use to Jira issue resolution. See app admin guide for more details.