December 2010 Archives

Definition of Done or Working agreement?

| 2 Comments

Definition of Done is the agreement between Product Owner and team. As ultimate goal, team is delivering potentially shippable product increment every sprint, thus, your Definition of Done shall be equal to what's required to make your product increment potentially shippable. However, your current Done may be only part of what's needed to get potentially shippable, constrained by your current technical capability. When we defined our Definition of Done several years ago, I found that we also added some criteria that are not really part of what's required for being potentially shippable. For example, we may make our product potentially shippable without automating the tests, though we added automated tests into our definition of Done. Why did we add them? Because we'd like to make sure that our development is sustainable. If we rely on manual tests, we shall soon find that regression efforts go up exponentially. We can not really afford, thus, we may not do regression in full all the time. Then, every now and then, we break existing functionality without knowing it. What's in Done and potentially shippable is actually no broken old functionality, while test automation is a practical mean towards that. I realized that there are two kinds of criteria in Definition of Done. One is customer/product and result oriented, which are all required to become potentially shippable; the other is process oriented, which defines the way of working. Over time, i also noticed that when team got mature, they tended to have less process oriented criteria in their definition of Done.


During a recent co-training with my colleague Emerson, I learnt from him that he always included those process-oriented criteria into working agreement. That is interesting, and it makes me wonder why we took different approaches and what differences they actually have. Here's my thoughts. Although it seems trivial since team will do according to both Done and working agreement anyway, there are profound differences. Scrum team is self-managing under certain boundaries. The most important ones are timebox in sprint, and Definition of Done. Organization and Product Owner executes the control through setting the boundary, while team self-manages within the boundary. Working agreement is completely up to team, thus, it's not part of the boundary set by the organization and Product Owner. In my environment, while we adopted Scrum, the concerns about self-managing still prevailed and the feeling of uncertainty from management was still strong. Thus, we kept more control by setting strict boundary through adding more process oriented criteria into Done. On the contrary, Emerson's environment seemed putting more trust on team, thus, they left those to the working agreement, which is created and owned completely by team. Either consciously or unconsciously, we chose the different approaches based on different assumptions and level of trust, and control.


Have you noticed the difference and what's the assumption behind your approach?


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.


About this Archive

This page is an archive of entries from December 2010 listed from newest to oldest.

February 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.