Commitment, what's your confidence level?

In Scrum, there are release commitment and sprint commitment. Though we use the word of commitment all the time, it is often not clear what it means.

Let's first look at the commitment we make towards customers. This happens at release level. In some situation, we need to make the release commitment soon after creating the initial product backlog in release planning. We first create product backlog items, then, estimate their size. We can add up the size of all items targeted at the current release, and based on the velocity, get to know how long the release may take. Team and Product Owner are supposed to work together on this. Is the outcome from release planning the commitment from team (for this set of features, we commit to deliver after certain number of sprints)? No, it is not, since team only commits on sprint basis. However, Product Owner may still need to process the outcome further and commit to customers properly. How should he do then? In the book "The art of Agile development" by James Shore and Shane Warden, there is one chapter for risk management, which incorporates some ideas from the book "Waltzing with Bears: managing risk on software projects". For more details, i recommend you to read those books. Here's a briefing about the approach for committing the release.

There are generic risks and specific risks. I would leave specific risks for you to dig more. We assume that you are using disciplined approach in your development, i.e. get items really done at the end of each sprint. I shall illustrate this from schedule viewpoint, via padding time to gain higher confidence level, but you can pad optional content as well.

Suppose that the overall size for the release is 100 points, and our average velocity is 20 points per sprint, it will derive to 5-sprint duration. Considering risks from emergent requirements, inherent uncertainty in the estimate, possible personnel turnover, this will give you 10% confidence level. Taking that as base, you can increase it to 50% confidence level by adding 40% more time (x1.4) into release schedule, and 90% confidence level by adding 80% more time (x1.8). Please be noted that those are only experience data built in Riskology, and you may go with your own data. How would Product Owner commit? Ideally, we have full transparency with customers and make inspection and adaptation on sprint basis, then, we do not need to make release level commitment. However, that requires high level of trust between customer and your organization, which you may not yet have right now. Thus, customers may still request commitment from your side. What does commitment mean here? Depending on your context. If this is very hard promise, as they typically are, the commitment shall go with 90% confidence level. Meanwhile, you may take 50% confidence level as your stretch goal in the organization. Unfortunately, most organizations mix them, which leads to taking stretch goal as commitment and pressuring teams to deliver by sacrificing Done and qualify.

If we say that release commitment goes with 90% confidence level, how shall we understand the sprint commitment then?

First, let's look at the risks in planning a sprint. Comparing to release, the uncertainty from one sprint shall be much less. We may not consider the risks from emergent requirements and personnel turnover, however, the uncertainty from the estimate still remains. Anyway, software development is not very predictable. So, i would say that if you commit for sprint based on your average velocity, you may get more than 10% confidence level. Does it give your 50% confidence level? Maybe. 90%? I don't think so. For 90%, you need to play more safe, since sprint is time boxed, thus, you can not pad time, so, you under commit content.

Shall we commit our sprint with 50% confidence level or 90% confidence level? First, let's look at two scenarios we often meet in Scrum implementation. Some teams take commitment as best effort, so, they are happy with whatever they complete, e.g. commit 5 items, and get 2 done. And it keeps going sprint by sprint. Other teams take commitment as hard promise. This may be related to the organizational measurement for how well your sprint goes based on the percentage of committed items done at the end of sprint, assuming that 100% is the best. I would say that neither scenarios are good. Why? Let's think about the reasons why Scrum asks team to commit for sprint goal. Commitment given by team itself shall help team more focused and more productive. There is also motivational factor, it gives team a sense of achievement. Does Product Owner rely on team's commitment to manage the release? A bit, but mainly Product Owner shall manage the release based on velocity, which is the actual, rather than the committed velocity. Looking at those reasons, i would say that neither taking commitment lightly - just trying the best, nor playing safe and going for 90% confidence level serve the purpose of commitment practice. Stretch goal with 50% confidence level is good balance point. Note, 50% confidence level means that you are 50% likely to get all committed items done (if you commit one item less, you may increase your confidence level to 90%), but does not mean that you will get only half of committed items done.

One last point, the meaning of commitment shall be part of your transparency. You do need to make sure that Product Owner and Team understand the same way, otherwise, the stretching part of the commitment may damage the trust.