Guideline: Iteration Status Report and Burndown Charts |
This guideline describes iteration status reporting as a way to provide objective data about the state of a software development project at the time of the reporting. Charting the information quickly and easily conveys necessary information, reducing the length of status meetings.
Main Description
Status reporting states where the project is in relation to the business goals, project plan, and implementation schedule. The quality of the implemented functionality to date is also tracked but may not be required as a status item, yet it might be very useful in decision making. There are different perspectives of status reporting in a software development project: the internal and external perspectives, as detailed on the next sections. #### Internal Perspective This perspective is the development team's view of the project state. As the team moves through an iteration, weekly or daily status meetings allow the team to identify the functionality implemented. This perspective provides the lowest level of status reporting and tracking. The cumulative amount of implemented functionality provides a trend of project performance. Visually representing a cumulative amount shows a development team where they are in relation to the total amount of functionality needed implemented by the end of the project with the appropriate level of quality, that is, a successful project to the development team. Presenting this in a burndown chart quickly provides the team a view of their progress. Seeing the trend promotes discussion among the development team to identify corrective action and gain commitment on the recommendations for improving project performance. The following charts represent a project in the third iteration with an overall length of eight iterations. Chart A depicts how much functionality has been implemented to date from the total functionality that was to be implemented at the beginning of the project. Chart B adds a trend line to show that if the team continues to perform at the continued rate they should be confident they will successfully complete their project and implement all functionality, potentially earlier than the scheduled eight iterations. There was significant improvement between iteration two and three. This improvement could mean either of two things: the most difficult and complex functionality had been implemented by iteration 3 or the team took the action to make changes resulting in improved project performance. Chart A - Functionality implemented throughout the iterations Chart B - Trend of functionality implemented throughout iterations Chart C represents a project that appears in bad shape. However, appearances may prove deceiving. This could also be representative of a project that expected to take at least four iterations to implement the most difficult, complex functionality. In that case, iteration five would see a significant improvement. Or, this project may have attempted to take corrective actions in the second iteration but either they were ineffective or additional roadblocks appeared. The development team members need to share their progress and identify issues they are facing, resulting in a list that is frequently reviewed to insure timely closure of individual issues. A growing list of action items with no resolutions indicates an unhealthy project environment. If project teams do not make progress with the implementation of functionality, it might imply projects destined to exceed budget and schedule. Decision makers need to be careful not to jump to conclusions too soon. In the example, work performed in iteration 4 and beyond could be less complex. That being the case, it would be expected that productivity would drastically increase in iteration 4. This level of information should be reflected in the project plan. Chart C - A project potentially in bad shape #### External Perspective This perspective provides business stakeholders (department heads, directors, etc.) outside of the project development team with visibility into the state of the project. This visibility is necessary in order to gauge performance towards the achievement of business goals and the achievement of planned payback schedule or Return on Investment (ROI). The informational elements providing this external perspective of the state of the project are: The cumulative amount of functionality that has been implemented The amount of functionality yet to be implemented The amount of budget that has been consumed The amount of schedule that has been consumed Key issues affecting project performance Recommendations for project improvement, if needed Providing management with a view into the amount of functionality implemented enables decision makers of the program or portfolio with an understanding of project performance. From a business point of view, a successful project will: Perform to plan Provide the requested business functionality Achieve the planned payback or ROI The need for this visibility provides decision makers with timely information necessary to either: Allow the project to continue Help improve the state of the project through reduction in scope and its ramifications to the business goals Introduce a project-level change request to increase the budget and extend the schedule, or Cancel the project Presenting a visual representation of the budget consumed, for example, with a trend line over three iterations (burn rate) quickly points out whether or not a project is healthy, as shown in Chart D. However, budget consumption by itself needs to be viewed in light of the amount of functionality that has been implemented to date. Chart E represents the display of both budget consumption and the amount of functionality implemented. Chart D - Trend of budget consumed (burn rate) throughout the iterations Chart E - Budget consumption and amount of functionality implemented Charting the budget expenditures in this manner quickly informs the business stakeholders, without much dialog, that: Budget is being consumed at a much faster rate than estimated At the current rate of consumption, the originally allocated budget will not be sufficient to complete the implementation of the remaining functionality In addition to visual representations, key issues affecting the project - along with recommendations for improving the state of the project - need to be presented. Some organizations set aside special meetings with the business stakeholders for project managers to quickly present project status. Providing visual representations reduces the need for excessive dialog, thus reducing the amount of time required for the presentations. Presenting status information in a dashboard significantly cuts down the amount of time anyone needs to devote to status meetings with business stakeholders. These status meetings may only be necessary for projects that need to address questions like: What is the cause for exceeding the burn rate? What is the cause for not developing the expected functionality according to plan? Is the project creating too much risk for the business? What are the plans for getting back on track? How close to the original estimates will the project deliver? What useful functionality can be delivered to the business if scope is reduced? What payback will be received with scope reduction? Will the business begin realizing the reduced payback sooner?
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.