One of the biggest challenges of developing mobile apps using an Agile process framework is determining when a feature (or even the app itself) is done and ready for use. A common pitfall for Agile app development teams is to fall into a perpetual iteration spiral of bug fixes, changes, refactoring, hardening, documentation, performance improvements, scaling, and even more innovations—without ever releasing a feature set to the user or customer.
The Agile family of process frameworks and production methodologies offers a few techniques to bring closure to a feature, but none provide the necessary degree of deterministic finality. In this post, we’ll explore three individual closure techniques: Scrum’s Definition of Done, James Shore’s “Done Done” (or done, done, done…) and Eric Ries’ MVP. Each of these techniques offers guidance as to when a feature should be considered done and release-able.
The Scrum process framework guide devotes a whole section to the “Definition of Done.” The basic premise behind this artifact and activity of Scrum is the establishment of a punch-list of all agreed-upon criteria required to call a feature (or story) done and award the development team credit for finishing the work. This approach may work for those features and apps that can be built and delivered within a single development iteration. But for more epic stories, for more mature development practices, and for larger product development organizations, this approach will eventually break down due to the fact that a feature’s workload can easily span several iterations. This poses the very real risk of the feature’s never being fully completed and/or released.
James Shore, in his “Art of Agile Development,” explains the aspects of doneness every Agile team should consider. He describes the meaning behind the phrase “done done,” and outlines completion-criteria, including a fully integrated, debugged, documented, deployed—and even optimized—feature. Other Agilists have expanded this concept by adding more “dones” (“done/done/done/done”), each of which describes progressive states of completion. This approach is a bit more prescriptive than Scrum’s “Definition of Done” in that, instead of having teams create their own lists, it enumerates the criteria of completion with a list of very mature software development practices. In the end, Scrum and Shore both agree—a feature can only be considered done when the customer can use it as intended.
Then along came the Lean Startup. Eric Ries re-introduced us all to the concept of a minimally viable product (MVP). Ries encouraged development teams to release features as soon as they are usable, as soon as they are able to bring value to the customer. Usefulness and value are his primary criteria for considering something ‘done’ within a development iteration, trumping everything else. Quality, maturity, and optimization are not necessarily prerequisites for being done, rather they can be achieved in successive product iterations when intelligence is gathered from customers using the product. Development activities that do not have intrinsic value to the customer should not be gating factors for a release. In contrast to Shore’s Done Done, Ries does not actually offer a finish line, but instead offers some basic criteria regarding where to start.
These three techniques will help Agile teams determine when a feature should be released to the customer. But none really brings closure to feature development. As long as a feature is being used, its development cycle has not ended. There is only one way to know for sure when a feature is truly complete—when no one wants it anymore. Our experience in the real world suggests we are never really done with any feature or app until it comes to rest in dormancy and obsolescence. There are usually more bugs to be found, better innovations to be implemented, and greater optimizations that have us perpetually cycling through the backlogs of our mobile apps. Don’t spend too much time wrestling with agreements, checklists, analytics and completion criterion. Instead, simply push a feature as soon as it can be used and will return value to the customer on their development investment. Commit to maturing the feature or app over time and as required by the customer. And never consider the feature done until it has fully run the course of its useful life.