BurnUp

From senseadapt
Jump to: navigation, search

Test

Burn-up / Landing Zone

This page describes how to select and set the variables for the chart.

Go to Reading the Burn-up interpret what the chart is telling you.

Purpose

Provide stakeholders with a realistic expectation of when they can expect delivery of a release. It clearly shows that there are two key variables that determine the ‘Landing Zone’ for a project. The Scope and throughput rate.

Project Data Settings

Select the Collection, Project, Iteration Path and, if needed, the Area Path.

Note: The work item defaults to PBI or equivalent. This does not work for tasks or features

Then push the ‘Load’ button to get the data. The image should appear below – you can hide this selection panel with the ‘Hide’ button.

You can save this if you want to share with others later- if you don’t want to share with others, then there is no need to save.


To unhide the selection panel – click the select data button at the top.

Image: Burn-up selection panel

BurnUp1.png

The Mode 2 History filter enables you to amend the query to include work items that are no long in the query. There is more detail on filter here

See here for more information on working of the Data tree selection

==Saving a report to share URL==You can save a visual – with all of the customised states, i.e. start date, forecast settings etc. Give the visual a meaningful name and save.

Image: Saving report

BurnUp7.png

You will then get a URL which can be shared with others – or included in a team wiki. http://visualisation.ripple-rock.com/BurnUp/View/38

Adjusting Forecast Settings

Having selected the data you can amend a number of elements of the chart, for both Scope and Throughput (aka ‘velocity’) These settings are changed by clicking on the chart settings button.

Image: Select chart forecast settings

BurnUp3.png

Which opens up the panel below.

Image: Chart forecast panel

BurnUp4.png


Note: you can either use the sliders or type a number directly into the box for each variable

More information on the calculations used in the Burn-up

1 - Select Dates and Interval

  • Choose the date that the project effectively started. If you are using scrum, ensure that this is the same as the date the first sprint started.
    • Select the data interval. You can sample the historical data at different frequencies. If using Scrum, use the same as the length of your sprints (in calendar days, not work days i.e. two weeks = 14 days)
    • Select the start date for the chart

2 - Adjust Throughput settings

Enables you to override or correct the forecast throughput rates. This is done by varying the history used in the calculations and the confidence levels.

  • Sample = select how much of the project history you want to include the calculation of the mean. 75% of the history will start from a date that was 25% into the project.
  • Set standard deviations for the optimistic (Opt) and pessimistic (Pes) projections of throughput

3 - Adjust Scope settings

Enables you to incorporate variables that will affect the remaining work to do.

  • Sample = select how much of the project history you want to include the calculation of the actual mean scope trend
  • Upper and Lower are the rates at which the scope growth is reduced interval-by-interval into the future.
    • i.e. -10 means that each interval (e.g. 14 days, defined on the left hand of the panel), the rate of growth in the Scope is reduced by 10% until it reaches zero growth
  • Note: this should reflect all of the work still to do i.e. not just ‘functional scope’ – see below for more details.

Future scope, or more acutely ‘work to do’, comprises several variables, that should be considered when choosing the settings for the project.

  1. Emerging functional requirements.
    • The product owner or users is likely to be continuing to add and refine the scope based on lessons learned from functionality delivered earlier.
  2. Rework
    • There is likely to be bugs and rework due to quality issues when the solution is integrated with other elements or is moved into higher environments. The amount of rework will be influenced by the quality of the definition of done that the team has been able to achieve. If the DoD is limited then you will probably need to include more effort for rework
  3. Non-functional work, in order to go live
    • This will vary project by project. It’s reasonable to expect that the first release of a project may have additional overhead of non-functional work to automate deployments whereas a later release may be able to utilise

4 - Define 'Done' for this chart

  • Choose which state(s) represent the done states for this project for this team. This is important to show the throughput line at the bottom. If you set a done state that is not realistic for the team then it is difficult to see their progress and the likely 'Landing Zone'

5 - Manual throughput

  • You can use this to add the throughput value that you expect for this team. You should do this if there is no prior history that could be used by the application. This should be done by the throughput rate or 'velocity' of the team.
  • The 'Manual range' refers to the spread of the optimistic and pessimistic lines.