NOTE: In "Building Highly Productive Teams: Work Committed vs. Done", I introduced the commitment-to-progress ratio as a measure that helps establish how far the team is able to embrace their tasks. I also described some positive and negative scenarios of relations between the committed and delivered work each team might be faced with. Now, for the second and last part of this article.
The Nature of Your Work
If the subject you are working on is at least in some part predictable by nature, you should be able to foresee some possible work outcomes; a high predictability characterizes the deterministic systems. Consider the following process of making a cup of tea: First, you boil the water; second, you put leaves of tea into a cup; third, you pour boiling water into the cup; and finally, you let the tea cool until it is ready for drinking. In this case, it is pretty easy for you to give estimates because variability is reduced to the likelihood of human failure or some external circumstance beyond your control that can negatively affect the tea-making process. Now, let’s take a look at the dispatching department of a company that runs a web shop: Because the nature of processing an order—receiving, packaging, and sending an item—is deterministic, you might expect to make straightforward estimates. For example, if employees follow the procedures, it will take five hours to process around 1,000 orders. In case of a machine failure, you should correct your estimates with the necessary time required to fix the issue.
On the other hand, there are tasks, such as the designing of a new product or the creation of a new algorithm, that require your creativity and patience. Instead of being accustomed to using “carved in stone” procedures, you must be able to think outside the box while being creative and patient. In the end, it’s very difficult to predict the results of these highly creative tasks, no matter how many times you make a guess.
Software development tasks reside somewhere between these two spectrums. In my opinion, the average complexity of software tasks would be around 0.7 on the creativity axis, where one represents tasks like a proof for a complex mathematical theorem. You must be more creative for the tasks that are less predictable in nature; consecutively, it may be harder for you to achieve a high commitment-to-progress ratio.
Some tasks simply do not fit with the concept of ensuring a low difference between the committed and delivered work. While creating a new architecture from scratch may raise your creativity meter to 0.9, asking a team to estimate if it will take two or four sprints to create a new O (n log n) clustering algorithm simply misses the point. It’s difficult to predict how much time it will take to make a breakthrough in mathematics, especially in two week sprints.
Definition of “Done”
The definition of “done” is one of agile software development’s key concepts, and it also plays a crucial role in helping you achieve the high commitment-to-progress ratio. When you have reached “done,” you’ve effectively made progress. A good definition of “done” clearly and concisely explains the criteria for marking the work item as done, focuses on business value, and only contains the necessary technical details that ensure that business value is delivered.
A poor and vaguely specified definition of “done” can lead to a misunderstanding about the reason to deliver, because a product owner may have a different opinion than the team. Your ability to measure the commitment-to-progress ratio can be utterly diminished, rendering useless all your efforts to achieve a high commitment-to-progress ratio.