Project TimeLine enables managers to plan the implementation of Releases and Epics.

What does “planning“ mean here?

Managers can set:

1. Planned Start Date (the expected date when the work on this Release/Epic will start. Note: For the reports to provide meaningful forecasts, it is important that the start date is the real date when the team starts closing issues in Jira)

2. Planned End Date (the expected date when the work on this Release/Epic will finish)

3. Planned Daily Velocity (e.g. 6h planned velocity per Release means that you expect 6h to be spent on this Release every working day)

4. What is in scope (these are the issues part of the Release/Epic)

Project TimeLine takes this “plan“ together with additional information from Jira such as the estimates of issues part of this Release/Epic, the logged hours and remaining hours, and represents all this information on the Release/Epic screen as shown below.

Open

How to plan a Release?

Step 1: Open the Release view of the TimeLine and click on a Release bar to expand it.

Open

Step 2: Click the Plan button.

Step 3: Fill in the required information in the Plan Dialog:

1. Planned Start Date

2. Planned End Date

3. Planned Daily Velocity

4. Once you fill in the information the Feasibility check will automatically calculate if this plan is feasible: if the scope (= total of all estimates of unresolved issues) can be done with the planned daily velocity for the working days between the planned start and end dates

How to plan an Epic?

Planning an Epic follows the same steps.

The only difference is that there are two more ways to schedule an Epic:

• by linking Epic’s dates to the dates of the Releases it belongs

• by linking Epic’s dates to custom fields in Jira

You can read more here: https://tools4teams.atlassian.net/wiki/spaces/PT/pages/602767517/Planning+directly+on+the+TimeLine+-+DRAFT#Auto-Scheduling-Options-for-Epics.

Where can I see the forecasted end date?

The forecasted end date is called Calculated End Date. You can see it by expanding the Release/Epic bar and check the “Schedule”.

Is my plan feasible by the planned end date?

There are two ways to see that a plan is not realistic:

• During the planning in the Feasibility check: in the Plan dialog (as described in How to plan a Release?)

• By checking the Calculated End Date on the expanded Release/Epic:

  • If the Calculated End Date is after the Planned End Date, then the plan doesn’t look feasible. The date is in red. A hover provides more details such as how many days later, etc.

  • If the Calculated End Date is before the Planned End Date, then the plan looks feasible. The date is in green. A hover shows how many days earlier, etc.

Where can I see which issues may drop?

Expand the Release/Epic bar and scroll down to see the table with issues. If the Calculated End Date is in red, this means there are more issues in the Release/Epic than can be done with the planned velocity by the planned end. There is a red line (2.): issues below it can not be done by the planned end date. You may also use (1.) the filter “May not be done“ - which shows only the issues that may drop (2.) below the line.

This may be a signal to add more people to the team, negotiate a later end date or review the scope and potentially reduce it.

Where can I see the impact of the unestimated issues?

Why is it important to know the number of unestimated issues?

For example, we have a Release that is 100% Work Done but there are 10 more Stories part of this Release that is not done and does not have estimates. On the surface, it looks as though the work goes on track, but once those issues are estimated, then you can get a better sense of the needed remaining time to complete it.

The number of unestimated issues is indicated in several places:

1. In the Work Done progress - you can see the number of unestimated issues

2. You can use the filter Unestimated to see only unestimated issues in the table below

Whenever there is progress or forecast the number of unestimated issues is also shown so that the progress can be interpreted in context.