Project control for agile projects is slightly different than for “normal” projects because of the self-organizing teams – especially because there is usually no project manager and no project controller. In this and the next article you will get an overview of how project control is carried out in agile projects. This article shows you how agile projects are planned and in the next article how they are monitored and controlled.
Project Control is not a Topic in Agile Projects
You may wonder why project control is not a topic in agile projects. Also the well-known Scrum Guide doesn’t mention this term. But I can assure you already now that project control is also done in agile projects—only slightly different.
The terms project control, planning, monitoring and controlling may sound very weird or old-fashioned to many agilists and scrumers, or are simply unsuitable for them—although agile teams carry out very similar activities, but these are simply named differently. This article is not intended to introduce the term project control to agile projects, It will show you how project control is done in agile projects—and this is done much more effective than in traditional projects.
If you are not yet familiar with agile project management and Scrum, you can get an overview here first.
Overview 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 Scrum works.
The Challenge of Controlling Agile Projects
With agile projects you want to keep the “administrative” project effort as low as possible, that’s why you often hear the saying: “The more you work according to plan, the more you get what you have planned, but not what the customer needs”, or “forget planning … we are “agile” … we solve future problems tomorrow.”. That’s why an agile project usually only plans the next short period (iteration/sprint/timebox) of 1-4 weeks in detail. What follows in the next 4 weeks is only roughly planned, everything after that can be found in the mission statement. Of course, these are not the best conditions for traditional project control, since project control probably also falls under the “administrative effort” mentioned above.
In practice, it’s not as bad as it looks at first glance, because even with agile projects you don’t live into the day as easily as you might think. The customer knows what approximately he wants as a project result (project scope) and is willing to pay for it (costs), and when he wants the result (time). These are the parameters that project control mainly deals with.
You will probably still ask yourself: “Who does project controlling here and what instruments/methods are used? Read on and learn how agile projects are planned.
Planning Agile Projects
Goals, Requirements
In traditional software development, all requirements are defined as completely and precisely as possible at the beginning of the project. Only then is a detailed project plan developed. In Scrum, requirements description, planning and implementation are carried in a timely manner and overlapping.
More about Requirements Management for Agile Projects
The Product Owner represents the needs of customers, users and other stakeholders. How many requirements the product owner prepares for the next sprint depends on the developers development velocity. The central tool to capture and manage requirements is the Product Backlog. The product backlog changes throughout the project: existing requirements are implemented, new requirements are added, existing requirements are changed, refined or dropped, and the priority of requirements can change. The efforts of all product backlog entries are estimated by the developers.
The Three Planning Levels in Scrum
Project planning for agile projects is based on rolling wave planning. This means that it is planned on three time levels and only the obvious is planned in detail. Project planning is carried out on the following levels:
- Release planning – (medium-term planning)
- Sprint planning (iteration planning)
- Daily Scrum – Workday Planning
Release Planning – Medium-Term Planning
The Product Owner creates the release plan and updates it before each sprint. The release plan provides an overview of the time frame, cost frame, and dates for intermediate results. It roughly shows the order in which the requirements are implemented and the expected number of sprints. At first, planning is only rough. In the course of the project, the release plan is regularly further detailed by the product owner so that he can monitor and control the project effectively. Risks are also specifically addressed.
The Sprint Planning
At the beginning of each sprint, the entire Scrum team meets for the Sprint Planning Meeting. This lasts a maximum of one day (for a 4 week sprint) and is used to define the “work package” (sprint backlog) for the developers for the upcoming sprint. The Product Owner presents the Product Backlog Items with the highest priority to the team and names the sprint goal with which the developers must agree. Together, both sides determine which part of the product backlog the team can turn into a shippable product increment in the upcoming sprint. This then corresponds to the Sprint Backlog. The developers plans the sprint by breaking down the relevant requirements into activities.
Daily Scrum – Workday Planning and Monitoring
The 15-minute Daily Scrum Meeting is a status meeting where sprint progress is determined, team members coordinate and inform each other, and the next 24 hours are scheduled. At this stand-up meeting, participants are best placed in a semicircle around the taskboard, which displays the sprint backlog with requirements and activities and their progress.
The Scrum Master takes part in the Daily Scrum, notes impediments on his impediment list and moderates if necessary. If possible, the product owner also participates in the Daily Scrum to stay up to date and answer questions if necessary. Only the developers speak and report the following to each other:
- What did I achieve yesterday to help the Scrum team achieve the sprint goal?
- What will I do today to help the Scrum team achieve the sprint goal?
- Do I see any impediments preventing me or the Scrum team from achieving the sprint goal?
Pay Special Attention to This When Planning Agile Projects
Plan only as much as necessary. Each client has his own ideas about what he wants to receive, what it will cost and by when the software should be ready for operation. This is the starting point for the initial planning – of course with the knowledge that many parameters will change during the course of the project. The motto here is: Only plan as much as necessary, not as much as possible, because it usually comes differently than you think. At the beginning of the project, however, at least the first sprint should be planned in detail.
Shorter sprints are better. The time planning always consists of equal time periods (sprints) of 1-4 weeks. Keep the sprints as short as possible. This makes monitoring easier and new functionalities are delivered more frequently.
A release plan gives an overview. A higher-level release plan shows, especially for larger projects, when larger functions are delivered and how many sprints are required. It is also a “cost baseline” for the customer and a good tool for controlling the project.
Only plan the nearby in detail. Only the current sprint is planned in detail. For the other sprints, there is only a rough plan. This corresponds to the well-known principle of “Rolling Wave Planning”.
Gantt charts only as an overview. Gantt charts do not have the same importance in agile projects as in traditional project planning. A high-level Gantt chart can be helpful to maintain an overview and to recognize important dependencies – but more is not useful. For detailed planning, sprint task lists or the task board are the best tools.
The developers plans. The developers organizes themself. They plan the sprints and assigns the tasks to themself. They knows the dependencies of the work best and can fully contribute their knowledge.
Requirements-based planning procedure. Plan requirements (user stories) within the sprints, not tasks such as design, test. For example, Sprint 4 for an online e-commerce system could contain the following requirements: “Implement Search for Books”, “Implement Search for DVDs”, “Implement Process Credit Card Payment”. The detailed planning can then be carried out by the team members themselves in sprint planning 2 or during the sprint.
Dealing with risks early. If a requirement is associated with a risk, this requirement is given high priority and implemented as soon as possible. In this way, uncertainties and open points can be dealt with early in the project before they become a source of fire.
Cost Planning
Cost planning is often an unpopular chapter even in traditional projects, but it is often ignored in agile projects. When it comes to fixed-price contracts for agile projects, the resistance is high and the understanding low. Many product owners claim that it is not possible to make reasonably accurate cost planning for agile projects. However, I am sure that the internal or external client is interested in what the project costs and what they get for it.
When it comes to fixed-price contracts, the requirements must be almost completely specified before the contract is awarded and remain as stable as possible during the course of the project. This scenario contradicts the idea of an agile approach. However, many traditional projects also have to struggle with this problem and sometimes exceed their budget massively.
I can give you the following tips for cost planning in agile projects:
- If a fixed price is required, you can only agree on such a price for individual milestones, releases or sprints.
- Make deeper preliminary clarifications with experienced colleagues (Agile Modeling, Architecture Envisioning) in order to gain a deeper understanding of the requirements.
- After the clarification of the order and the first rough planning (based on the rough requirements), give your client only a rough area estimate, e.g. $700,000 … $1,200,000.
- For relatively detailed fixed-price contracts, well-established change request management and claim management processes are unavoidable.
Learn more about How to Apply Contracts Effectively to Agile Projects.
Who is Responsible for Planning?
The product owner is responsible for the requirements, product backlog and release planning. Also for the first part of sprint planning (when it comes to WHAT). The developers are responsible for the second part of the sprint planning (when it comes to HOW) and also for the daily planning in the sprint.
You haven’t read much about the Scrum Master yet. But his role is not unimportant, because he supports the Scrum team in planning, coaches and trains the team where necessary and moderates the planning meetings.
As a repetition the most important points again:
- The Product Owner determines the project and sprint goals, as well as the requirements to be implemented
- The developers determines how many requirements they can implement in the sprint and do the detailed sprint planning.
- Only the current sprint is planned in detail. The other sprints and releases are only roughly planned (rolling wave planning).
- The developers monitor their own work progress in the Daily Scrum and treat impediments immediately.
This was the first part of the article “Project controlling for agile projects” with the project planning. The second part with monitoring and control follows soon.
This was an overview, how agile projects are planned. In the part 2 of this article you will learn How to Monitor and Control Agile Projects.
Here is 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 Scrum can make your agile projects even more successful? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!
Do you know anyone who might be interested in this article? Then simply forward it or share it in your network. Thank you very much!
