Você está na página 1de 2

Definition of done

Abstract
Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your teams definition of done. Verifying that your teams definition of done meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well. The definition of done can also be seen as: a checklist of valuable activities required to produce software useful reporting mechanism for team members, an input for reporting is informed by reality is not static (extendable and can make exceptions) is an auditable checklist

Rationale
The definition of done will help the team making sure that the implementation meet expected behavior. Another equally important aspect is that the definition of done will help the team focus on the code, system and team quality attributes. Code quality examples: Coding standard compliance, its highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Architectural review, aligning the new code to fit existing architecture and design principles makes sure the system can meet NFRs. Tested, automated tests are vital to regression testing, the business of ensuring that new changes in code don't break things that were working before. Documented, clearly documented code support integration and understanding of the intent of a specific component or method.

Product/System quality examples: Integrated, a change should not be considered done until its fully integrated and working as expected. (There are cases where the final consumer is still not implemented but the integration can usually be verified with automated tests.) Usability, testing usability early will avoid future redesign and customer feedback. NFR, there is little use of new functionality that will not meet the non-functional requirements since this will probably just increase the technical depth.

Team quality examples: Do not over-commit, predicable velocity, adding new features as fast as possible will give a first impression that the teams are high performing. Later when technical depth is catching up the speed will radically start to slow down.

Technical debt, Pay me now or pay me later, making sure we upfront pay enough attention to quality will help the teams delivering new features in a sustainable pace. Knowledge sharing, using techniques like code review will boost code quality, team knowledge, understanding of the system design principles and increase developer skills.

Scaling definition of done


For completeness and integrity you would have three different levels of definition of done. Even though the same rules apply for all types of activities they have slight different acceptance criteria depending of the activity size and stakeholder involvement.
1. Task: a task is a unit of work that contributes to the fulfillment and completion of a scheduled work item. Tasks allow decomposition of scheduled items into manageable units of work. Team members can take responsibility or ownership for each task, providing estimates and remaining time for completion. 2. Story: a story is a statement of functionality formulated as a few sentences in the everyday language of the user that can be completed within an iteration. The team takes responsibility for fulfilling the story and meeting the specifications of the acceptance criteria. 3. Feature: a feature is a service provided by the system that fulfills one or more stakeholder needs. Often multiple teams collaborate in completing stories that together builds up the feature.

Example
The table below recommends activities used to build the definition of done on the three levels. Task (team member) Acceptance criteria Coding standards Unit test Compiler acceptance Static code analysis Code review Dynamic code analysis Green CI Accepted by Team Story (team) Acceptance test Meet NFR Architectural review Documented No known defects Accepted by PO Feature (multiple teams) Acceptance test Meet NFR Full regression test Integrated to mainline Exploratory testing Accepted by PM

Você também pode gostar