Why doesn’t the definition of done include value?
At its core, the question asks how can we consider work “done” if there is no business value delivered, even if the definition of done is satisfied including demonstrably meeting acceptance criteria. Is software are really done if the business need has changed so what was delivered is technically correct, but misses the mark based on the business environment today? This is a scenario I was all to familiar with during the 1980s and 1990s at the height of large waterfall projects, but see less in today’s Agile development environment. Anteneh Berhane’s question reminds us that the problem is still possible. We discussed five potential problems that disrupt the linkage between done and value. Today we will discuss the first two and here are the remaining three.
An incredibly dynamic business environment can be a huge contributor to the potential of delivering software that does not have value (or the anticipated value). Conceptually this is the simplest contributor to develop an understanding of, but nearly impossible to solve. The good news is that in a typical business environment this problem rarely occurs. Whole business environments rarely change in a week or two weeks. This problem is more apt to be seen on battlefields and in sporting events. In these scenarios, needs may evolve so quickly so that the original short-term acceptance criteria may not be translated to value. Continuous planning/re-planning and delivery techniques such as Kanban are potential solutions. Planning and testing continuously generate the feedback needed to stay on track.
Long sprints can be a mechanism that irrationally perpetuates the waterfall cycle. One of the first time boxes proposed by Champy (Champy and Hammer, Reengineering the Corporation) in the 1990s was delivering every 90 days. In those 90 days, you could easily do a small waterfall story. In today’s Agile, a typical sprint is 2 weeks or 10 business days; during which time the world does not change too much. However, there are still organizations with month-long (or longer) iterations. The longer the sprint the higher the probability that the business need will change. The simplest fix for this type of problem is to reduce the duration of the sprint to a time frame where functionality can be delivered that meets the business needs.