Since the beginning of software development, project managers have been trying to tame the three-headed monster known as the iron triangle: scope, schedule, and budget. Historically, the battle was fought by creating extensive project plans detailing exactly what will be delivered, by when, and at what cost. 200-page functional requirement documents, milestones carved in stone, budgets planned down to the penny, and an unlimited amount of assumptions made along the way only increased the chances of being bitten by the beast.
Given the rapid production capabilities that tech companies have at their disposal today, by the time you finally publish that novella-like plan, your competition has likely beaten you to the market. The trick to conquering the iron triangle and creating valuable products quickly has less to do with detailed project plans and more to do with managing project execution risk.
The practice of Agile development does not give you a license to execute without a plan. In fact, it requires you to continually iterate your plan and milestones based on new information learned throughout the project. At Devbridge, we leverage data-driven metrics to increase project transparency, continually communicate with our clients, and create an atmosphere of shared understanding throughout the project lifecycle. Below are some of the metrics we use to identify and address project risks.
Burn down sprints, burn up releases
How can you ensure successful sprints? We use sprint burndown charts to track the amount of work remaining in a sprint and to determine whether a sprint is on track.
On the other hand, when tracking the progress of a release, we use burnup charts. If sprints use burndown charts, then why do we use burnup charts for releases? Well, burndown charts are great tools for measuring progress when scope doesn’t change (like in sprints). On the other hand, the scope of an agile release changes constantly due to stakeholder feedback, so a different metric is needed that visualizes changing scope. This is where the power of a burnup chart comes into play.
By tracking release scope and average sprint velocity, we can use the burnup chart to forecast release dates for projects in real time. In the example below, the burnup chart indicates that the release will be completed in the ninth sprint. Assuming two-week sprints, we can approximate that the project will take four to five months to complete.
We use a similar approach to forecast project spend. By tracking the average cost per sprint, and using the release burnup chart above to determine the approximate number of remaining sprints, we can forecast the total cost for a given release. For example, if a project has an average sprint cost of $20,000, and we estimate a total of nine sprints in the release, we can approximate the total release cost to be $180,000. We can then compare this forecast to the project budget in order to identify budgetary risks early on in the release. For this example, the burnup chart indicates a risk of running out of budget by the end of the seventh sprint.
Strive for sprint consistency
The presence of risk in sprints becomes apparent when looking at a team’s historical sprint velocity. If the team’s velocity chart looks like your favorite roller coaster, there’s a good chance that your team is carrying around a lot of risk. Lack of consistency in a team's velocity undermines your ability to forecast accurately, so it’s important to identify and address root causes of velocity variability.
Here are some things to take into consideration if you are having problems maintaining sprint velocity consistency:
Changes in team composition
When a team’s composition changes, either by adding or removing people from the team, your team’s velocity is bound to change due to on-boarding and familiarization. Try to keep your teams consistent whenever possible.
Improper story sizing
If a story is sized incorrectly, it will cause spikes and dips in your team’s velocity. Don’t worry about updating the size of completed stories. Instead, focus on verifying that your remaining backlog stories are properly sized based on what your team has learned.
If stories are not being completed and continue to be carried through multiple sprints, consider putting fewer stories into a sprint. Then swarm your team members onto stories to identify and resolve team bottlenecks.
Holidays and vacations
Holidays and vacations affect velocity, too. If a team member is going to be out for an extended period of time, consider supplementing the missing team member with another resource so that you don’t adversely impact your release forecast.
Drive behaviors, not metrics
The most important thing to remember when using metrics to manage project risk and team performance is to use metrics to drive the right behaviors within your teams. What can be measured can be gamed. What can be gamed will be gamed. Metrics are useful, but not when they are used as a weapon against a team. Use metrics to identify risk within a team and start a conversation with your team members and clients.
By using data-driven metrics to forecast project status, we can continually monitor the iron triangle monster for risks and address them early in the release. Agile releases are successful because they allow teams to identify potential pitfalls well before it is too late to address them. Are you forecasting project overspend or a missed release date? Time to prioritize backlog and cut scope. Can’t cut scope? Consider adding additional resources to your team. By leveraging metrics, fostering open communication with clients, and embracing transparency we are able to master the iron triangle.