You may wonder why project control is not a topic in agile projects. Even the well-known Scrum Guide does not mention this term. But I can already tell you that project control is also carried out in agile projects. Project control for agile projects is somewhat different from “normal” projects, because the Scrum team is self-managing and there is no project manager or project controller. In the first article you already got an overview of how agile projects are planned. In this article, I show you how agile projects are monitored and controlled.
If you are not yet familiar with Agile Project Management and Scrum, you can get an overview here first.
Overview about Agile Project Management
As you can read in detail in my books on project control, project control comprises the following three main activities: planning, monitoring and controlling. These activities are also carried out in agile projects, but somewhat differently and, in my opinion, much more efficiently. In this article, I will show you how a Scrum project is monitored and controlled.
How to Monitor Progress
Knowing the progress of the work at any time is not only important for the Scrum team but also for the senior management and the stakeholders. A comprehensive project control and weekly or monthly status reports, as with traditional projects, do not exist in Scrum. However, this does not mean that the progress of the project, releases or sprints is not monitored and reported.
In Scrum, work, progress and results are monitored in each Daily Scrum and in each Sprint Review. In case of deviations from the plan, one can quickly initiate actions, reschedule, possibly adapt the procedure and learn from it (inspect, adapt and learn).
At the sprint level, the Scrum team has very effective tools to monitor project progress with the Daily Scrum, Taskboard and Burndown Charts. This allows the team to identify problems early, take action quickly and solve problems while it’s still easy. This is a great advantage over non-agile projects.
The reports* that the developers create show which user stories have been implemented and whether work is progressing as planned. However, they do not show how much work has been done. In Scrum, it is not important who has worked how much and for how long. What is relevant is what functionality has already been delivered and where you stand in product development.
* They are actually not reports, but Scrum artifacts. However, they are very useful when senior management or a sponsor wants to have periodic reports that show the progress of the project.
Openness and maximum transparency in the Scrum team, and towards stakeholders is one of the five Scrum Values. Therefore, the Scrum team should make the information about the sprint or release progress as easily accessible as possible to all stakeholders. This creates trust, interest, and commitment. A picture of the taskboard, burndown or parking lot charts are good tools for this.
The following “reports” are often used in Scrum. Here in order of importance:
- Taskboard
- Sprint Burndown Chart
- Product Burnup Chart
- Release Burndup-Chart
- Parking-Lot-Chart
- Velocitiy Chart
The Taskboard
The taskboard represents the sprint backlog and gives an overview of all user stories that will be implemented in the sprint, the associated tasks and shows the work progress. The development team is the owner of the Sprint Backlog and the Taskboard. The taskboard shows the current plan to reach the sprint goal. It is also at the center of the Daily Scrum Meeting, which focuses on progress and impediments. It is the information center in the sprint!
The user stories are broken down into activities in the Sprint Backlog. These are described in detail, estimated in person-hours and last if possible not longer than one working day. This helps to track project progress on a daily basis and to identify problems at an early stage.
The Sprint Backlog changes daily. At the end of the working day at the latest, the development team members update their activities and estimate the remaining effort. Some teams do this during the Daily Scrum or when new information becomes available. If the Sprint Backlog is updated regularly in this way, you always work with current information and the progress of the project is always transparent for the Scrum team and the stakeholders.
The taskboard, as a daily updated report about all work in the sprint, is a bit disparagingly said, actually only a “board” with a lot of notes on it and may not be a report for you. But take a photo of it and you have the best overview for your stakeholders what the current status of the ongoing sprint is. This is a very informative report that can be produced with little effort. Therefore, in my opinion, it is the most important report.
The Taskboard is an ideal monitoring and controlling instrument.
The Sprint Burndown Chart
In the Sprint Burndown Chart, the Developers visualize the remaining work in relation to the remaining time in the Sprint. It fully meets the requirements of reporting in the following ways:
- It is easy to create with little effort.
- It is drawn by the developers themselves.
- It is up-to-date every day.
- It is always visible and creates urgency.
The Sprint Burndown Chart shows the Scrum Team the following information:
- The remaining work needed until the end of the Sprint
- Any deviations from the planned work progress
- The development velocity
Note: Real progress in the Sprint is only achieved when the work results are approved by the Product Owner at the end of the Sprint, because only approved results can be used.
How to Create the Sprint Burndown Chart
In the Sprint planning session, the Developers summarize the efforts of all activities of the user stories which need to be implemented and enter these on the vertical axis of the chart. On the horizontal axis, they enter the number of working days of the Sprint and then draws a line from the point on the vertical axis to the last working day on the horizontal axis. This is then the ideal line of progress (Ideal Burndown).
At the end of each working day, the Developers update the Sprint Backlog. Then, the remaining effort of all activities which have not yet been completed is added up and entered on the Sprint Burndown Chart on the corresponding day. If you connect these points, you have the actual burndown.
Evaluating the Sprint Burndown Chart
The trend of the remaining effort drops with the Sprint duration and should arrive on the horizontal axis at the end of the Sprint at the latest, i.e., it should be “0”.
If the actual burndown line is below the ideal burndown line, you are making progress faster than planned. If the line is above, you are making slower progress than planned. The actual burndown line increases if, for example, the number of activities has increased, you have misjudged the effort, or you had to start an activity over again.
With the Sprint Burndown Chart the Scrum Team quickly recognizes whether the remaining work is decreasing as expected and whether it can most likely develop all functionalities up to the end of the Sprint.
Irregularities in the burndown chart indicate problems with estimates, capacity planning or scope-creep. They should be addressed by the team during Sprint execution, but also in the Sprint Retrospective.
Should the ideal line in a burndown chart be changed when the story scope changes during the Sprint? No. If you add new work in the third week of a Sprint, you won’t rebase the starting value. This would be misleading. Instead, you will show a rise in the amount of work remaining for this Sprint.
The Release Burnup Chart
Scrum Teams often use burnup charts for Sprints or releases. In the following figure I will show you a release burnout chart. The planned Sprints for the release are plotted on the horizontal axis. On the vertical axis is the effort in story points for the entire release. The chart also shows the target line, which is the total planned effort for the release. The dashed line rising from Point 0 to the end of the release shows the planned average velocity.
At the end of each Sprint, the Development Team updates the release burnout chart to show the work done during the Sprint. If you connect the points after several Sprints, you can clearly see the current average velocity that has been reached up to this point in time. After four Sprints, this would be 200/4=50 story points per Sprint. This is a bit more than planned.
The primary advantage of a burnup chart over a burndown chart is that changes to scope are evident by a change in the scope target line, as you can see in this example.
The Story Burndown Chart
Some Scrum Teams use Sprint Backlog items (user stories) for their burndown chart instead of the remaining effort of the activities. On the vertical axis there are story points instead of hours. The result is a staircase curve, because there are far fewer stories than activities and there is not one story finished every day.
The story Burndown Chart clearly shows how much functionality was delivered during a certain period of time and what is still open.
The Parking Lot Diagram
The Parking Lot Diagram is a report originally taken from Feature Driven Development (FDD). For the Product Owner, it is important to know the degree of completion of functionality clusters and, thus, their release capability. The level indicators on the diagram provide a quick overview of the progress of the project and the application.
The parking lot diagram is updated at the end of each Sprint. For each topic you determine the number of story points of the already accepted user stories and the total number of story points of the still outstanding user stories.
The Velocity Chart
As you have already read, the velocity of development is not constant; rather, it varies. If the velocity has levelled out after a while, you can easily see whether the team is in a high or low phase. For example, if the velocity slows down, this may be due to impediments or absenteeism. But, a change in team capacity also has a relevant influence on the velocity.
Note: The Velocity Chart is not intended to be a tool for monitoring the team, but it is an important tool for the Sprint and release planning.
The velocity of development helps you to calibrate the release plan and to generate the release burndown report (Cohn, 2014). The report with the velocity chart is created after the first Sprint and is then updated after each completed Sprint.
How the Agile Project is Controlled
In Scrum, work, progress and results are monitored in each Daily Scrum and in each Sprint Review. In case of deviations from the plan, the Scrum Team can quickly initiate actions, reschedule, possibly adapt processes and learn from it (inspect, adapt and learn).
When it comes to the actual work in the sprint, the developers themselves decide on the appropriate measures, since are self-managed. They themselves will move a user story to the next sprint if it is no longer achievable or, in consultation with the product owner, cancel it if, contrary to expectations, it cannot be implemented.
On a higher level, the Product Owner controls. For example, only the product owner is entitled to cancel a sprint—even if he does so on the advice of the stakeholders, the developers or the Scrum Master. The product owner also controls the Product Backlog, i.e. he coordinates the priorities of functionalities with the customer and stakeholders. He then decides on the composition and sequence of the user stories and their distribution to releases and sprints.
Nobody should tell me that costs do not play a role in agile projects! With the sprint and release planning and the days worked by the Scrum team, the product owner also has an overview of the current project costs.
The developers decide themselves about the appropriate measures, because they are self-managed.
Here You Can Find More Knowledge
This was an overview of monitoring and controlling agile projects. What experience did you have with controlling agile projects? Do you agree with my statements or do you have another view or additions? Share your experience with me and the readers in the comment box below. Thank you!
Would you like to learn more about how to make your projects more successful with Scrum and Agile Project Management? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!
Do you know somebody who might be interested in this article? Then forward it or share it. Thank you!
