Assess Your Project’s Risks
Projects have risks. That’s because you cannot manage the work with a checklist. Your project is more complex than a checklist. Your project will have risks with how the team thinks about the domain and solves the problems: technical risks. In addition, your team might have other risks, especially in the areas of scope, cost, people, and schedule.
Every project, including agile projects, has risks. I use the following pyramid to consider the risks for my project. I find that there are inside-the-project risks and outside-the-project risks.
When projects start, management often wants to fix the outside of the pyramid: the project cost, the project environment, and the people and their capabilities. Inside those constraints, the project can deliver some number of features, with some expected defect levels in some time.
In reality, the project team can change almost any of these. I bet you’ve seen projects where management decided it was okay to spend more money to deliver more features. I bet you’ve also seen projects where you started with not quite enough people and you managed to get more people on the project.
Since we expect to change the feature set with agile approaches, you may have more flexibility than you realize with the feature set and the date. I’ve seen agile projects end much earlier than anyone expected because they had completed enough features for now and had no WIP.
Some managers want to see a budget for a project. An agile project has an easy budget: the run rate for the expected amount of time plus the capital equipment costs.
An agile budget is easy because the team members remain on this (and only this) project for the entire project. If you need to, you can estimate the "entire" project, as covered in Create Approximate Estimates for Management. Do remind the managers who need an up-front budget that you expect the product backlog to change and you might be done earlier.
If you need to provide and manage a budget, make sure the entire team is dedicated to your project and no one attempts to multitask. When people leave or join a team, the team incurs a cost of delay while they learn to work together. The more important the budget is, the more you need a stable team.
If you do need to monitor a project’s budget, add that to your reports, as detailed in Chapter 14, Report Your Project State.
You might have risks from Avoid Management Mayhem. One way to assess your potential risks is to conduct a retrospective for work or a project these team members just completed. Their experiences (and yours) will help the team think about risks they want to review and manage.
Consider asking the team how it wants to manage risks. Sometimes creating a board of the top 10 risks and managing those risks during problem-solving meetings or planning meetings might be enough. Consider a board of risks, impediments, and concerns that the team evaluates on a regular cadence. See Visualize Problems with a Board.