The past particle “done” as understood in literal English means; “Completed, accepted and ready”. Not to be confused with the adjective ‘done’ as often used in colloquial English meaning; “tired out and half-finished”.
However simplistic, perhaps by stressing the literal definition in the context of Agile Project Management, particularly within the field of software development, we can begin at a fundamental starting point when trying to illustrate the basic concept of what is generally recognized as ‘Done’ in Scrum. In contrast, the English colloquialism ‘done’ can describe what may end up being the result of poorly defined and poorly implemented criteria for Done.
Why Define Done?
Completed, accepted, ready and most importantly, the aspects of quality and value, are not the same for me as they are for you. So, even in the flexible world of Agile Management, Scrum teams working within their varying user stories require a set of rules which lead to a Definition of Done in order to understand if a story has been truly integrated and fulfilled within a project. It is a forecast of what is achievable and complementing this checklist is the fact that what will be delivered is made transparent within the organization.
Completion is not only that the story has met all its acceptance criteria but also that a code review has taken place, the product has been tested, and it is now ready for shipping. Without a universally accepted definition within an organization, both Scrum teams and individuals within them will quite naturally create their own diverse and subjective ones. Hence, without some sort of shared understanding of criteria, it will be extremely difficult to release a quality product or features of a quality product at the end of each sprint since a checklist guiding pre-implementation activities including discussion, estimation and design will not have been followed. One apt analogy for this process and its desirability could be the use of the comprehensive flight check routine undertaken by aircraft pilots before every take-off.
Done Criteria
Done Criteria need to be made up of all, or most of, the following key elements set within a designated time-box and must be fully satisfied before we can truly say that something is Done:
–The product has been reviewed and accepted by all team members.
-The product has been thoroughly tested.
–Quality assurance tests have taken place.
-All documentation in the User Story is complete.
-There are no outstanding issues.
-Stakeholders and Business Representatives have witnessed and approved successful demonstrations.
In layman’s terms again, why not imagine you are the head chef in a world-famous beef steak restaurant and the new owner has had a sudden impulse to put armadillo steaks on the menu? Would you just source it, buy it, cook it and start serving it on a whim? Probably not if you were proud of your reputation and that of the restaurant. Most certainly you would think about rigorously applying certain parts of the above project development criteria before plating up the new dish and serving it to your customers. As a footnote, for those of you who have not tried to cook or have not tasted armadillo, I can almost guarantee that unfortunately your sprint would undoubtedly be cancelled very early on.
Deciding What You Define as Done and Implementing it
Deciding
Before creating your own Definition of Done, think about the two key aspects of a user story; quality and value, since these can help guide you towards your own definition. Base the Done Criteria upon these two points and a more complete result will be achieved since all of them aim at quality whilst reducing cost. In addition, try not to be constrained by believing that you should only use the recognized Done criteria because in your sprints and overall project other testing agents and yardsticks may be appropriate and applicable. Furthermore, consider if the Done criteria which you are applying are realistic for the team members in your particular workplace. If things are approached and done logically, methodically and correctly the first time within any development process the cost of having to redo them is undoubtedly removed.
Implementing
In very practical terms, implementation means discussing together the practicality of your Done criteria with all the team or teams and then deciding which are the most appropriate. Then, as obvious as it may seem, it is of the greatest importance to actually physically post a list of the criteria in a very visible place. This is most likely to be in the location where your Daily Scrum/ Stand-up Meeting is held; the team’s task board
Shared and Multiple Definitions of Done
In many projects a host of Scrum teams may be working on different features (the software developers, the marketing department, the finance department, etc) and thus despite their different roles in the process to create and release the final product, a shared definition of Done will need to be agreed upon by all the teams involved.
In some cases in some projects, organizations think it necessary to create multiple definitions of Done beyond the accepted norm. Different features may require different approaches and criteria to reach a satisfactory end result. This idea, however, could be thought of as leading to unnecessary over-complication although alternatives to it do exist.
Re-Evaluating Your Definition of Done
The world of Agile Project management is fluid and this ideally includes your definition of Done. The way in which it is viewed by the team will alter positively in line with their effectiveness and productivity. With their ongoing
Should Done Extend Beyond The Scrum?
It is usually thought that when a new product has been ticked off as Done and is at the stage of being ready for shipment it can truly be defined as Done. Nevertheless, it could be argued that Done should extend beyond the confines of the workplace and the product’s actual development process to include the customer’s viewpoint. Both by informing them about the product to be released and by taking on board a certain amount of their feedback, where considered relevant, one would surely have a more complete picture of its quality in particular. Let’s face it, the success of the product ultimately depends upon its uptake by future users so why not have them involved in a pro-active way at an earlier stage?
Beyond that, could the implementation of Done criteria be considered as extending as far as an assessment of a product’s viability and suitability once it is actually in the marketplace? Namely, when a product has been released and is in use by customers. Some organizations believe that this should be the case and hence, as mentioned before, Done should really relate to the job at hand and may well include multiple extended definitions depending upon different circumstances.
Not Done but Still Done
“Not done but still done” sounds like a contradiction in terms but in fact is a relevant aspect of the complete concept of Done in Scrum. It takes into account the less likely instances when a sprint has been cancelled on the authority of the Product Owner before the end of its time-box. Despite
Let’s think armadillo steaks again. Once tested and tasted you almost certainly won’t like the idea of having the final product in your world-famous beef steak restaurant but you may well have achieved positive quality results elsewhere, such as in gaining extraordinary leads in sourcing uncommon food products. Therefore, one feature of the sprint is definitely reusable in other upcoming projects.
Potential Dangers of Done Definitions
Having a definition of Done in Scrum is fundamental in each sprint from the planning stage onwards but its possible drawbacks need to be considered in order that they can be avoided or controlled:
-First and foremost, are all team members fully aware of its contents?
-Is it too obsessive and pedantic thus decelerating progress?
-Is the definition regularly reviewed and discussed by all team members in order to continually assess its suitability?
-How easy is it for new teams within an organization to integrate into both an established definition and into a reviewed definition of Done?
-Does it stretch team members enough to achieve results but not so much that it ends up with fewer stories being completed within sprints?
-Are elements sometimes too easily accepted and signed off by the Product Owner when they are not really Done just in order to speed up the production process?
Overall, despite the potential dangers which can be mastered with a little forethought, tighter control and adaptability, in the