The Definition of Done

We take building trust with our clients seriously and defining done helps to secure that trust.

Why is it a critical theme throughout the full scope of software development?

Beginning with a generalism, anyone who works in technology, specifically software, can attest to the fact that we frequently find ourselves speaking in acronyms. For those of you less familiar with these tech terms, I’m going to include a cheat sheet at the bottom of this post.

When explained by the Agile Methodology*, each scrum team* has its own definition of done and consistent acceptance criteria across all of their user stories*. A common thread however is that the various definitions of done all drive the quality of work as it is used to assess when a chunk of work has been completed from user stories to sprints* and projects. It’s imperative to the success of a sprint, release, and overall project that each team establishes their own agreed upon definition of done prior to starting the chunk of work. Additionally, it is critical that this definition is shared with and signed off on by the client.

To define how I see success in done, let’s use a sprint for an example. In Agile, sprint planning happens on the first day of the sprint. During this planning meeting, the definition of done is defined by the team altogether – from product managers to design, software development, and quality assurance.

This may include:

• The user stories, tasks, and bugs that will be completed by the development team.
• The test cases to be written and those to be completed by the quality assurance team.
• Any mock-ups, wireframes, resources, and additional UI/UX elements* that will be completed.
• Any necessary requirements, roadblocks, or tasks that need attention by the product manager, business analysts, and other team members.

This exercise allows the team to commit to an amount of work that they will complete in a set amount of time – typically two weeks. Each team member then signs off on the list and is responsible for ensuring his or her portion of the completion. By having each team member sign off, they are holding themselves accountable for the chunk of work.

Not only does defining the list to be completed allow the team to think through the work ahead of them, but it allows the team to set client expectations on when and what will be completed/ delivered by the end of the sprint. I find that clients appreciate frequent and early progress, which is a major reason Agile is so successful as a methodology.

By leveraging this concept in all of the engagements at Rivers Agile, we’ve been able to commit to timelines and budgets – and stick to them as we approach project finish lines.

Definitions

• Agile Methodology: An approach to software development followed by product managers in which continual planning, team collaboration, and responding flexibly to project changes are of the utmost importance.
• Scrum Team: A cross-functional team of product management, design, software development, and quality assurance testing all working toward a common goal following Agile Methodology.
• User Stories: Small well-defined chunks of work that can be completed in whole by the development team. The requirements of a user story are as follows: As a [user or user role] I need to [action/functionality that system needs to do] so that [reason for the action/functionality].
• Sprint: Used as benchmarks, typically in two week increments, a sprint is used to help the team accomplish goals while all working toward the completion of the larger project.
• UI/UX Elements: User interface and user experience elements are design components that make up a portion of product design, all ensuring that software is easily understood by the end user with little-to-no training required.