Edelweiss - Fotolia
Calibrate your definition of 'done' in Scrum to meet requirements
Get together with business leaders before software launches and find common ground to define done. One company's idea of perfect code is another's lurking disaster.
The definition of done means many different things to different Scrum and Agile teams. Generally, done acknowledges that software met its requirements to move from one phase of the development process to the next. For a startup seeking an early stake in the market, the definition of done in Scrum has a wholly different connotation that could ultimately determine its product's viability.
In most cases, the definition of done documents the delivery of a feature, user story or release that adds value to the business. Done, as a concept in the Scrum framework and Agile methodology, applies standard acceptance criteria to development and test processes, and it defines the commitment to quality shared across the team. These guidelines are the basis for estimation and story pointing accuracy, sprint execution and software delivery.
To determine what qualifies as done, the team must establish a shared understanding of quality via a checklist of tasks to complete during the sprint and production release. Doneness forms the Agile and Scrum version of phase gates to software development. The definition of done is especially critical for startups, as it codifies the development team's agreements with business owners, thus making sure they are satisfied with the delivery. Business owners use the definition of done to make acceptance and release decisions.
Define your done
To create your own definition of done, it might be tempting to start with some specific questions to avoid ambiguity. However, you can address these feature-specific questions in the acceptance criteria. Instead, focus on what the business owner requires in terms of code review, unit testing, functional testing and usability.
Startups, which have no existing products in the target marketplace, can struggle to define the level of quality required for their definition of done, but the founders' vision for the product is a good place to start. Also, assess the competitive climate and market in which the startup operates. Is the product related to health or safety? Are there government regulations to meet? If so, the definition of done in Scrum or Agile models is more likely to require in-depth testing and documentation compared to other launches.
It is also critical to evaluate the founders' risk tolerance. The IT team needs to help the founders understand the tradeoffs of quality versus speed to market. This tradeoff forms the basis of the decision-making involved in developing the definition of done in Scrum.
What if the mission is simply to introduce a new technology? In that case, a startup's success might hinge on being the first to market. In this case, the startup could ease quality requirements to prioritize a faster release. For most organizations, the definition of done likely resides somewhere in between these two extremes.
On the same page
The whole organization, founders included, must understand the definition of done and how it applies to the software development lifecycle, even if that means a series of meetings to explain how the organization benefits from following these concepts within the Scrum framework and Agile methodology.
Ultimately, it takes the commitment of the team, the founders and the product owners to come to an agreement on a definition of done in Scrum development. If those three groups are on the same page, developers and testers can work under a shared understanding of, as well as a commitment to, quality.
