3. Forecast
The Forecast page provides forecasts for work items at Backlog level (PBI, User Story, Bug, etc.). It excludes forecasting for number of items at any levels higher such as Epic or Feature. Task work item type is not included in the dataset.
For a very small number of users they experience the forecast page crashing - there is a workaround provided in this thread
Based on the number of items to forecast (using the drop down), what is the forecast completion date to a percentage likelihood.
The chart runs 10,000 simulations of different scenarios using the historical throughput data of the last 'n' weeks (controlled via the input data range filter). The output is a distribution of these simulations in forecasted completion date, with percentiles of likelihood. As well as this, the throughput stability percentage is shown (aim to keep this below 25%).
The current backlog size number is based on the number of items (PBI/User Stories & Bugs) in the backlog that are not in a Removed or Completed state.
The intended behaviour with this chart is to highlight that software/product development is complex. Traditional estimation from teams normally produces a single result and does not produce a likelihood of meeting that result. More often than not the result presented is only 50% likely due to dividing the remaining work by the average. This means the odds of that result are a coin-toss. This method allows the reader/customer/client to choose the amount of risk they wish to sign-up to, in particular if they want to deliver ‘everything’.
It can be misused in that it only gets used at the beginning of the project/product development. It should be continually inspected as part of your product/project progress. Another common mistake is not throwing away ‘old data’, which is something you should do if context/domain/team size changes. Use this chart to see if ‘everything’ is needed and re-prioritise scope.
Based on the number of weeks to forecast (using drop down), what is the percentage likelihood of completion in n number of items.
The chart runs 10,000 simulations of different scenarios using the historical throughput data of the last 12 weeks (controlled via the input data range filter). The output is a distribution of these simulations in number of items forecast to be delivered, with percentiles of likelihood. As well as this, the throughput stability percentage is shown (aim to keep this below 25%).
The intended behaviour with this chart is to highlight that software/product development is complex. Traditional estimation from teams normally produces a single result and does not produce a likelihood of meeting that result. More often than not the result presented is only 50% likely due to dividing the remaining work by the average. This means the odds of that result are a coin-toss. This method allows the reader/customer/client to choose the amount of risk they wish to sign-up to, in particular if they want to deliver ‘everything’.
It can be misused in that it only gets used at the beginning of the project/product development. It should be continually inspected as part of your product/project progress. Another common mistake is not throwing away ‘old data’, which is something you should do if context/domain/team size changes. Use this chart to see if ‘everything’ is needed and re-prioritise scope.