Once you have a structure containing the data for a project, you can use Structure.Deliver to manage the project around the target date you are trying to hit.

Adjusting Team Predictions

One of the major struggles at the beginning of a project is trying to understand the scope of the project before it has been fully specified. Sructure.Deliver allows teams to set expectations for how their backlogs will grow through the course of the project.

When a delivery is created, Structure.Deliver creates an initial set of metrics for each team based on historical data and the information provided in the source structure. If a team believes those numbers will change as the project proceeds, they can adjust the metrics during the Planning stage.

Once you click Save, the changes will be applied to the PCFD and Team Metrics Table. 

Team metrics can only be adjusted during the Planning stage.

Throughput

Throughput indicates the number of issues the team will complete in a given week. The initial metric is based on the team's historical performance.

If a team believes they will complete more (or fewer) issues each week than predicted by their historical data, they can adjust the throughput metric to their new prediction.

In the figure above, the Android team has indicated that it expects to complete one additional issue per week over its current metrics. Structure.Deliver notes this by putting a "+1" after the throughput number in the teams metrics row. The PCFD graph will be updated to use the adjusted throughput and the trending date will be updated accordingly for the team.

When the delivery is moved to In Development, the +1 will be changed to a -1, indicating the team is behind their planned throughput. As their actual throughput increases (or decreases), this number will be updated accordingly.

Epics

Epics indicate the number of epics required by the team to complete the delivery. The initial metric is based on the number of epics contained in the source structure.

In the figure above, the Android team believes their part of the delivery will require 12 epics worth of work. There are currently 11 epics for the team in the source structure (metric: 11), so this is an increase of 1 epic. In the Predicted column, a "+1" has been placed next to the epic icon, indicating Structure.Deliver expects 1 more epic to be added for the team at some point during the delivery.

As the project progresses, Structure.Deliver monitors the source structure and updates this column accordingly:

• When Structure.Deliver notices a new epic has been added to the source structure, it will subtract it from the expected number in the Predicted column.
• If more epics are added than were planned, Structure.Deliver will show a negative number in this column. For example, if the Android team adds 3 new epics, that would be 2 more than Structure.Deliver expects, so a "-2" would be shown in the Predicted column. This might indicate that the team is engaging in feature creep, is not tracking MVP, or had misunderstood the scope required to do the project.

Scope

Scope indicates the average number of stories per epic. In the figure above, the Android team is currently averaging 12 stories per epic, but they believe that will decrease to 11.

Aligning Target Date & Team Trending Dates

After teams have made their adjustments to the metrics, the Target Date is aligned with those new expectations.

In this example, after adding 3 simulated epics to the project, the Android team is now predicted to finish work after the target date.

At this point, leadership has several options for addressing this discrepancy:

• The target date could be moved out, in order to align it with Structure.Deliver's new prediction.
• Additional resources could be assigned to the Android team to help them make the target date.
• Tasks could be redistributed between the Android team and another team that is scheduled to complete their work before the target date.
• The overall scope of the delivery could be reduced, so that it can be completed by the original target date.