Hitting a release or iteration target is very problematic for new agile teams. The issue usually lies in weak agile processes. The root of the issue is understanding what work is left (the backlog) and how much work the team can do (velocity). Project estimation becomes a relatively simple and repeatable exercise once the team understands missing requirements and velocity. The issue with hitting targets lies in two major areas.
You are missing 20% of the requirements
For any release or milestone, the backlog is missing at least 20% of the requirements. However, this isn’t a big problem once a team accounts for the missing stories. Any backlog of work needs to be multiplied by 1.2x. Some teams may find that their “unknown factor” might be higher or lower. But usually, 1.2 is a reasonable starting place.
An example:
A team I recently worked with had an average weekly iteration velocity of 25 points. The release backlog contained 200 points. Without the unknown factor the release would be completed in 8 weeks. However, they kept missing delivery targets because stories were being added to the release. This is normal. Stories will always be added/removed from a release. This is part of the agile process.
However, there was friction between the Product Owner (PO) and the rest of the team. The PO was messaging to clients and business partners that the release would occur at the 8-week mark. The PO felt the team was letting him down. The tough conversations between the PO and the rest of the team were very stressful. The PO felt the team didn’t keep their 8-week commitment and the development team blamed the PO for changing scope and not informing the client.
The PO, representing the business, has the authority to change scope. Agile supports that. In addition, the development team has the authority to update the release target based on those changes.
However, there’s an issue. Some business messages can not be altered. There’s some inflexibility upstream of the development team. To account for this, teams need to understand that only 80% of the requirements are present in the backlog at the start of a release cycle. Once a release backlog is committed, multiply the aggregate points by 1.2 and get your total estimated velocity.
You don’t understand your velocity
Multiplying the release backlog points by 1.2 only works if the team has a good grasp of their iteration velocity. Oddly, even after 20 years of agile experience, there are still teams that don’t know their velocity. They either don’t understand stories, point estimation, iterations, story grooming, roll-overs, bugs versus stories, etc. These are all fundamental issues that need training and coaching. However, once points are understood, estimation becomes much easier.
If a team is producing 30 points a week and there’s a total estimated backlog of 120 points, that team will very likely complete that backlog of work in 4 weeks. It really doesn’t get much simpler than that. The problem lies in understanding a team’s velocity. It really is the fundamental underpinning of agile and is absolutely required if goal estimates are to be given to Product Owners.
As always, if your team needs help with agile coaching please reach out to me here.
