Agile project managers' daily challenge

As a project manager, you field questions all day. Leadership asks, “When will I see a return on our investments?” Stakeholders ask, “What can we do right now to improve outcomes later?” When you manage portfolio-level projects, hunting down the right answers — and communicating them effectively — can easily eat up your entire week.

Structure for Jira helps by collecting all of your project data, across all contributing teams and backlogs, in one place.

Now, it can use that data to help you more reliably predict completion dates.

More reliable project forecasting

In the age of Agile, one of the major problems for large-scale project planning is that not all of the requirements (normally contained in user stories) are known ahead of time. Agile teams create user stories through the grooming process, just in time for the next sprint. Without some idea of the total scope for a project, it is next to impossible to predict a delivery date.

How does Structure.Deliver solve this problem?

• Historical data. Structure.Deliver uses the rich store of historical data in Jira to make predictions about the future. It analyzes how teams typically break their work down and generate scope, developing team profiles that predict how many additional stories they are likely to generate for each project — even before that project's data is entered in Jira. The upshot: Structure.Deliver anticipates team performance, and estimates target completion dates for each team.
• Subjective edits and updates. After establishing that raw baseline, project managers can work with teams to refine the timeline as they see fit. They'll know things that Structure.Deliver cannot anticipate — whether a team has hired new developers and will likely move faster on this project, for example. By combining relevant subjective knowledge with the objective metrics, Structure.Deliver is able to create a project timeline that combines the best of both.
• Project tracking. Once the targets are set, Structure.Deliver helps you track progress against those targets throughout the project life cycle. The predictions adjust as new data is added to Jira, immediately reflecting new developments and alerting you if a team is tracking away from plan. This enables project managers to communicate and react to updates as they happen across all participating teams.

What does this look like?

Let's take a peek at how Structure.Deliver can help with a project already in progress. The scenario below shows an in-progress delivery, where Structure.Deliver uses the team performance data in each team's historical backlog to develop a metrics profile; it also analyzes the data in the structure that is connected to each delivery.

Imagine we have a structure that represents an initiative the organization is trying to deliver by a certain date. (In our sample project, initiatives are a Jira issue type that sit above epics. Deliver does not require a level above the epic.) It has a bunch of epics contributed by a number of teams. Some of the epics have been groomed into stories by the teams and some have not. Given the incomplete scope and the mix of priorities for the various teams, how can we answer the question “are we on track?”

Here’s a snippet of what that structure might look like:

Although we're still missing some data due to incomplete stories, we've gathered all available information from all the teams working on the initiative. Now, to answer the question, "when will it be done?" we'll connect Structure.Deliver to our structure and look at things from a different perspective. Here is what we get:

Explaining the Structure.Deliver user interface

Let's take a look at the different parts of the chart above.

1. Predictive Cumulative Flow Diagram
   You may already be familiar with Jira cumulative flow diagrams (CFD). They’re a great tool up to a point. With Structure.Deliver we’ve taken this concept to a new level — it provides a predictive cumulative flow diagram (PCFD). It shows past workflow transitions and the relevant Jira issue inventory to the current day. The "Y" axis of the PCFD shows the number of issues and the "X" axis shows the dates. The points on the graph show the date at which an issue was in a specific workflow state. Areas of the graph representing different states are color-coded.

   • Red—work that is still to do (in the backlog)
   • Blue—work that is in progress
   • Green—work that is done

   By plotting all of the issue transitions for the project, the graph shows a historical representation of project progress. The slope of each workflow state represents the rate at which work is being created and completed for a project.

2. Predicted Stories
   The steep cliff in the "To do" area of the graph at the line labeled "Today" is the result of the Structure.Deliver algorithm predicting the number of additional stories teams are likely to add to the project. The predicted stories are added to the known project scope (the scope that is defined in Jira) at the current date, "Today." This creates a steep jump in scope if there is still a lot of predicted scope for the project. This also creates a flat line across the top of the graph that is the predicted ending scope for the project. The predicted ending scope provides a final target for all work and is a major element of Structure.Deliver’s ability to predict trending dates for teams. Story prediction is per team and is based on each team’s historical grooming practices.

3. Completed Teams
   Teams that have completed all of their scope for the delivery are placed on the PCFD at the date they completed their last issue for the delivery. If scope is added to their backlog, they will be placed on the graph at the new predicted completion date.

4. Estimated Completion Dates
   The completion date is predicted by running the team's performance model against the remaining scope defined in Jira — plus the additional scope predicted by the algorithm for the team.

5. Today and Target Lines
   The Today line represents the transition point of the graph from a traditional, historical cumulative flow diagram to a predictive cumulative flow diagram. The portion of the graph to the right of the Today line represents the simulated future for each team working on the delivery. Teams that are predicted to finish after the Target date (which you provide during creation of the delivery) are flagged in red in the Metrics table to the right of the graph.

6. Team Metrics
   The Metrics section breaks down the key stats by team. There are five columns of data for each team, which provide some visibility into the underlying data that informs the predictions. This includes throughput by team, estimated future scope creation, and predicted completion dates by team.

Selecting a team in the metrics table changes the graph to show the PCFD for that team only. Here we have selected the Android team, and the graph now shows only that team’s performance for the initiative managed by our structure:

Addendum: Deliver Dashboard
One of Structure.Deliver's best contributions to Structure is its dashboard — a simple screen that tracks important high-level initiatives and acts as a central point of communication. Ideal for displaying on a large screen monitor at presentations or in work areas, it shows deliveries in various phases of completion, such as "Planning" and "In Development." With one look, viewers understand the status of the organization's top-level priorities.

Note: The dashboard respects the permission settings for a delivery's source structure. If a user does not have permission to view the source structure of a delivery, they will also not see the Delivery on the dashboard.

Let's back up: How to start a project

We just looked at some of the bells and whistles of an in-progress delivery, but what if you are starting a new initiative and no stories have been defined and no work has been done yet? If you have an epic-level scoping of the initiative, you can use Structure.Deliver to supply end dates, by team, based on the teams' historical scope breakdown of epics. Structure.Deliver will then use historical data from each team’s work history to simulate the completion of the new, planned initiative.

Let’s say you have a structure that contains only a partial scoping of epic-level requirement definitions for each contributing team:

None of these epics have any defined stories, and no team has done any work for the initiative yet. Also, the teams know that additional epics will be added later but are not sure exactly what they will be. In this case, Structure.Deliver allows for future epics to be indicated by each team as part of the planning process. Deliver will track the expected number of epics as the delivery progresses (read more about this in the next section).

Structure.Deliver uses the actual number of epics in the source structure plus the indicated number of future epics to predict the ending scope for the project. Using each team’s historical backlog to supply the team performance data, here is what a 100 percent simulated initiative looks like using Structure.Deliver:

Here we see which teams are predicted to generate the majority of scope, what throughput each team is likely to achieve, and the date they are predicted to complete their work. We recommend using this data to inform the conversation about what target dates each team can realistically achieve. Once those target dates are set, Structure.Deliver can be used to track against those dates and take action early in the SDLC to mitigate risks.

Tracking project progress: Getting early alerts so you can adapt quickly

Large projects are constantly buzzing with activity. Keeping up with updates to team scope changes and prioritization can burn up a lot of time and energy.

Structure.Deliver helps keep track of changes at the team level by tracking execution against expectations for each team’s throughput and scope generation that was set during planning. Deviations from the plan may be a warning sign, or just indicate a need to reset expectations — either way, Structure.Deliver provides data-driven updates that help users make decisions early.

The metrics data that Structure.Deliver presents also facilitates dialog between project managers, key stakeholders, and teams. Deliver's predictions are meant to start a conversation; teams respond to the predictions by adding self-assessments that modify predicted project completion dates.

In the picture above, the Billing team has indicated that they expect to achieve a throughput of 4.5 issues per week on this delivery. They have also indicated that they expect to create an additional four epics at some point in the project life cycle. (Note that these epics are not yet in Jira, but Structure.Deliver will use their indicated intent to predict the ending scope for the team.) As the team adds additional epics to the source structure, Structure.Deliver automatically updates its epics to reflect those changes.

It then tracks the progress of each team against the plan they set, raising signals early in the project life cycle so risks can be mitigated. If a team is not achieving the planned throughput, Structure.Deliver will indicate the difference between plan and actual achieved throughput (1, below). If a team has indicated it will be generating additional epics, Deliver will track the number of expected epics for each team (2, below). Deliver will also indicate if a team is generating more epics than planned.

Make predictions with what you have — even if you don't have a lot

Structure.Deliver is designed so that it doesn't require any additional data than is naturally available at each step of a normal project life cycle. Using Deliver, you can successfully plan a project with the kinds of artifacts that are normally available from Agile teams, specifically high-level requirements defined as epics. As the project matures, Structure.Deliver will track trends toward the desired targets.

How Do I Get Structure.Deliver?

Structure.Deliver is an extension for Structure, one of the leading Jira project management apps on the Atlassian Marketplace. For now, it's available for Jira Server. It may be used with Jira Data Center as well and “Approved for Data Center” status will be available shortly. Download a free 30-day evaluation whenever you’re ready to give it a try.

In addition, our SAFe^® implementation partner, Adaptavist — one of the leading worldwide Atlassian Solution Partners — is ready to help you fine-tune Deliver, for SAFe or other use cases. They will help you with:

• The optimization of your Jira configuration for the best possible predictions
• Training for your users
• Process integration support specific to your SDLC

If you’re interested in learning more about Structure.Deliver, visit the Atlassian Marketplace, contact our Deliver specialists, or get in touch with Adaptavist.

Read more about Agile execution in a waterfall world:

• Build a Project Roadmap Without Killing Your Agile Process
• Defuse Battles Between Leadership and Agile Teams