So you have a product backlog consisting of a nice list of user stories which have been loosely estimated by the team, and a team nearly ready to start ploughing through the exciting journey to building a product. You’re under pressure to get a deadline announced. What to do next?
Well at this point, I presume you don’t know the teams velocity as they haven’t started the project. Ideally the first thing to do (if possible) is to get one or two sprints done to get an idea of the teams velocity. You might be thinking that you know the teams velocity as they have just finished another project and it’s the same people. Don’t make the mistake of cross-applying the velocity to the new project. Each project presents different challenges and can be vastly different. If you presume to carry this over, I’m confident that you may be in for an unpleasant surprise!
After one or two sprints, you’ll have a rough starting figure from the velocity, or at the very least a list of problems which could drastically identify any fundamental issues missed during the product backlog derived from the retrospectives. Assuming you now have a velocity, you have your first step towards announcing a deadline.
Lets set the scene and say you have 1000 points in the product backlog and a cross functional team of 4 people to keep things simple. Your average velocity after the first two sprints is 100 points per sprint. Therefore you would be tempted to state the release backlog should be 10 sprints. At this point you might be thinking “Well I know that because we do retrospectives, and remove impediments, the team gets faster over time so I don’t need much of a contingency as the increased speed will give me some slack”. Don’t be tempted by this, it’s worth putting in a contingency as it protects yourself if your the PO and aligns business expectations. If you are ahead of schedule at the end, people are not generally going to be disappointed to hear you’re ahead of schedule or that you can develop more in the anticipated time frame.
Working out contingency can drastically vary between projects, companies, teams and environments. Depending on your knowledge and risk management strategy this can range from 5%-50%. A few things that I consider when calculating this, some of which have emerged from my own personal mistakes are :
- Consider increasing contingency when working with smaller teams. In the example above with a small team of 4, it’s not unlikely that one or even two people could leave during the project. That’s at least 25%-50% of the workforce gone. If you have many teams totalling 100 people, it’s unlikely you’ll loose 25%-50% of the workforce at exactly the same time.
- Consider the “Focus Factor” (A term I have borrowed from Henrik Kniberg : http://www.crisp.se/ScrumAndXpFromTheTrenches.html). Putting it simply, consider factors that could interrupt the teams concentration and commitment each sprint. The more of these, the lower the “Focus Factor”. The lower the focus factor, the lower the velocity and so forth. I suggest reading the above book for more depth on this topic.
- Account for absences and holidays. Even if you are looking ahead for the next 8 months and nobody in the team has holidays booked, this is not to say they won’t appear later down the line. Failure to account for these could be detrimental.
- Account for “White Noise”. The PO’s role is vital for the team to work in priority with enough detail and direction. If the PO is absent or distracted, there is a chance that the some focus will be lost for the up and coming user stories; similar to the “Focus Factor” mentioned above, but more related to the PO. This could be as a result of other business activity, sickness or general distraction from stakeholders.
- Consider that the less you know, the greater the risk. When you have identified what you consider to be the likely risks, remember that contingency is to account for unknown risks. Always include a metric for completely unknowns which are not part of the above, those which could be categorised, but not detailed.
All of the above considered should present you the path to calculating a contingency. Don’t be alarmed to see high rates of contingency such as 25%-50%. It’s better to be truthful in the long term rather than tell people what they want to hear in the short term and fail. I sympathise that you can say next September and some people hear next June, but that’s their input not your output.
Another factor worth highlighting here is that contingency isn’t necessarily a buffer for additional work. This is the case with the fundamental Agile philosophy of welcoming change. Change should always be welcomed, but contingency is not part of a project to insert additional work. If we have 8 months to deliver a product backlog with 1000 points with a 25% contingency level, the contingency is there to deliver 1000 points, NOT 1250 points. Therefore the PO should note that if during the sprint review new requirements emerge, these should be estimated and prioritised, but not inserted into the product backlog without consideration to the existing commitment. The additional story should either replace an item of lesser priority within the backlog of the same estimated value or if all is required for the version release, the deadline should be extended to accommodate the additional work and the stakeholders informed. Being transparent about this often helps truly prioritise the change in its true scale. Failure to remember this, will put pressure on the team and increase the risk of failure.
Contingency is often within the projects to account for unforeseen circumstances which are not part of the original project plan. If you overestimate the consequence could be an early release or undertaking more features than agreed to in the same time frame which is often received well. Underestimating on the other hand, lowers moral in the team, invokes lack of trust and lets the stakeholders down which could be very costly for everyone. Build in and plan the contingency well into the release backlog and remember that saying yes in the short term to tell others what they want to hear is counterproductive and high risk for the PO.
