1

Wrong dates of a project start/end or a release start/finish - that directly impacts how accurate a forecast can be - because it is relative to planned milestones. 

1. For the whole project - check in Project setup → Project settings. 

2. For the Release - check in your Tracking system (e.g. JIRA) - make sure all significant releases contain (i.e. not blank) valid dates of Start and End. 

3. For the Release - check in your Tracking system (e.g. JIRA) - make sure all significant releases Start dates are not future dates.

Adjust if necessary, then refresh the chart and/or run the data update.

2

Scope was/is uncontrollably creeping and that creep exceeds the Velocity of a team. At the same time, most likely, no appropriate adjustment of target milestones had been made. 

1. Validate the amount of actual scope creep - first check the the Burn Up chart. Example of a bad case: 
   
   

   Open

   

2. ... and then check the Sprint Plan Change, % chart. Example of a bad case: 
   

1. Consider a "scope freeze" - negotiate that with your stakeholders, jointly consider pros and cons. 

2. Introduce the scope change management - to control the unplanned work - 
   
   

   1. to make sure if added scope is authorized by your stakeholders (and of high priority, not just nice-to-have)

   2. to make sure if something added (assumed high priority) is compensated with something (of lower priority) being removed

   3. negotiate a milestone adjustment if more time is required to implement the extra

   4. negotiate a team ramp-up if more capacity is required to implement the extra in time

Target: creep within +10% (assumed it's under control). 

3

Requirements are of poor quality i.e. they are not fully ready for development. And this causes a big waste of effort on requirements clarification during a development cycle, not upfront. 

Do you have a "Definition-of-Ready" rule on a project?

Check the quality of BA/PO work via "Ready for Development" chart: usually if it's less than 2-3 sprints then you're in trouble:

Open

Make sure you have the "Definition-of-Ready" rule on a project - or introduce it. Set up appriate criteria at Scope Management step (of, e.g., JIRA connection) in project configuration and keep an eye on a few metrics: 

1. "Ready-for-Development" metric: (target is > 3 sprints)
   
   

2. Ready-for-Development in Active Sprint: (target is >90%)
   
   

4

Actual velocity of a team is poor. 

Validate the actual velocity - to recognize if it's poor and its trend:

and completion rate of a team: 

1. Retrospect with the team on reasons. Pay attention to the following suspects: 

   1. requirements are clear, sliced with a good granularity, contain consistent acceptance criteria (i.e. healthy requirements mean a good qualification of BA/PO team)

   2. estimation accuracy is +/- 20% (i.e. engineering team is capable to research the unclear scope, elaborate gaps, split the "elephant" into reasonable chunks of work for a transparency)

   3. technical qualification of developers and testers in the team (i.e. seniority level is enough for this project)

   4. seniority pyramid (i.e. it's well-balanced to ensure a smooth delegation-and-control of engineering tasks)

   5. team colocation, culture, language, timezone (i.e. to ensure an efficient communication between team members)

2. Dive further on root causes via data/metrics - check things which might contribute a lot into velocity degradation

   1. check work stoppages (impediments), see below in this article

   2. check blocked dependencies, see below in this article

5

Over-commitment of a team, i.e. people under-estimate their tasks generated from the scope of work to do. Such under-estimation can be caused by insufficient seniority/experience of team members, by poor requirements, by poor communication, etc. 

Assumed, a team is practicing their work being estimated in man-hours (otherwise, no chance to review estimation mistakes from data) - and their estimations are too optimistic

Conduct a retrospective session with a team to brainstorm root causes of wrong estimations. 

Target: variance +/- 10%

Good-looking estimation accuracy should like that:

6

Some work gets blocked by mistakes in dependencies management - i.e. a lot of work is naturally blocked by other work which is planned in wrong order. 

Take a look at the Improper Dependencies, to make sure it's Green, otherwise it highlights how much work is blocked. Example:  

Work with responsible stakeholders / customers / 3d party vendors - to elaborate and unblock the dependent scope via re-planning / re-sequencing e.g. stories between sprints or releases.  

Target: indication there're no wrong dependencies: 

7

Some work gets blocked (i.e. impediments appear) by unexpectedly raised questions during implementation - which requires appropriate parties to step in ASAP in order to unblock the team. 

Check the Number of Open Work Stoppages and their average lifetime to make sure it may be a reason. Below are  examples with a huge number impediments as of now (and growing trend i.e. situation is getting even worse) and terrible resolution lifetimes (and growing trend again). 

Work with responsible parties (in most cases these are Scrum Masters / Team Leaders, sometimes these are POs at Customer side) - to resolve the impediments. 

Quite often it's about chasing Customer for requirements clarification (by BA/PO/Dev team) to let those requirements pass the "Definition-of-Ready". 

Target: 0 open work stoppages, and their average lifetime is less than 72 hours.  

1

'Infinite' forecast i.e. chart says a project will never end

1. No fixed scope at the start of a project / release / sprint i.e. everything is considered as scope creep. 

2. A major fluctuation with the scope made recently e.g. something big is added into the backlog or got (re-)estimated which caused a scope explosion.

1. Burn Up is best used on fixed scope setups e.g. a Fixed scope or Fixed price projects - or Releases (with the scope of work planned in advance) or Sprints (with the scope of work planned in advance). If your project is not the case - look into Kanban metrics instead of Burn Up - Lead & Cycle Time, Throughput, Time-in-Status and so on. 

2. If the Burn Up is still your choice - take care about proper scoping and fight against a scope creep. 

3. Try un-checking the "Forecast with scope creep" checkbox in chart settings to assume a scope freeze - 

2

No 'Completed' deliverables on the chart

1. Wrong configuration of Definition-of-Done in the Project setup → "Workflows" step. 

2. Outdated status (e.g. in JIRA) for delivered stories e.g. still "In Progress" while actually accepted by stakeholders. 

3. No actual deliverables on a project by a team. 

1. Go to project setup, review statuses and workflows, adjust if necessary. 

2. Maintain an up-to-date status of stories / tickets in the tracking tool (Jira, Tfs, etc.)

3. Conduct a retrospective meeting with a team to find root causes of poor delivery and remediation steps.