Data and Charts
Each iteration produces data on the team's actual productivity, namely the total number of points achieved by completing stories. These two charts should be generated from this data:
1. Velocity-Time Chart
- x-axis: Time in iterations or dates (the last day of each iteration)
- y-axis: Velocity = points of completed stories within an iteration
- The first data point is generated after the first story implementation iteration.
- After a few iterations, the average velocity should be about constant for the rest of the project.
2. Burndown Chart
- x-axis: same as in velocity-time chart
- y-axis: Points remaining = sum of points from unfinished stories
- The first point starts at the very beginning of the project and is therefore at x = 0, just above the y-axis. It is the sum of the effort estimates of all stories. The seconds data point is generated after the first story implementation iteration.
- The linear approximation function of the data points has a negative slope. The deck of stories is completed over time, so the graph "burns down" over time, hence the name.
Benefits
- Measured Productivity: Real data, meaning hard facts, about actual team productivity and project progress that are far better than guesswork.
- Completion Date Estimation: The data can be used to estimate the completion date of a milestone or the project by either
- dividing the remaining points of all unfinished stories by the average velocity from the velocity-time plot, or
- creating a linear approximation function through the data points of the burndown chart and read the intersection with the x-axis. This marks the expected completion date of the milestone/project, as there are no more stories to implement.
- Note that this is only an estimate, not absolute truth. There is variance in the data points, which creates uncertainty, and unforeseen challenges may occur. This is just our best guess, and given the law of large numbers, it gets better as more data points are added.
- Increasing accuracy of estimates as the amount of data increases, i.e. as the project progresses. For example, it is common to estimate the first project completion date after 4-5 iterations and to update the project completion date estimate after each further iteration.
- Team Productivity Monitoring: In the event of significant productivity deviations due to internal problems, corrective action can be taken immediately.
- Easy to Understand: Interpretation of the charts is intuitive, so everyone involved in the project (team, business and customers) should be able to view the data at any time. The charts are of particular interest to management, as they provide exactly the information they need to do their job.
Declining Velocity
The most likely reason for declining velocity is poor code quality due to lack of refactoring and testing. Don't hide it, don't artificially inflate the velocity (see "Golden Story"), just invest more time in refactoring and testing to improve code quality.
How to Handle Delays?
If the Agile data produced indicates that there will be a delay, there are a number of ways to deal with the problem:
- Schedule Adaption: It's sometimes possible to postpone the deadline, although this is often not an acceptable option for management.
- Personnel Increase: Will result in a short-term drop in productivity, as the new team members require the attention of the original team members (explanations, answering questions, joint familiarization with the project, etc.), which distracts them from their actual work. After this period, productivity will rise above the original productivity as desired.
- Scope Adaption: Stakeholders prioritize features with the highest business value and remove low-value features from the project scope.
Decreasing code quality by omitting testing or refactoring is not an option, as it actually slows development and adds to technical debt.