When talking about building culture in the software development process, deciding on a team’s Definition of “Done” has become a major component in the shift to Agile — most commonly in Scrum — that ensures every player works together toward the same end goals.
For example, if a developer is working on a certain user story and tells the product owner they’re done but it hasn’t been tested, this will backup product release once the mistake has been realized, or potentially affect reputation if a buggy app is deployed without being caught.
While one person may be finished with their tasks, that does not mean the project is done as a whole, and saying so can limit progress if it’s not done in all parts and stages. Teams that do not consider this groundwork often find that it severely impacts productivity.
The Definition of Done for Scrum Teams
When Agile strives for iterative development, fast feedback, and adapting requirements, having limited communication will delay a team’s acceleration and pace when pushing a project or feature set to market.
Maybe you feel factors like testing, reviewing, documenting, releasing, or even collaboration should go without saying, but many team members will consider tasks done based on whether or not they fulfilled their individual role.
Because Scrum has lightweight management overhead and bi-weekly check-ins (Sprints), having a Definition of Done becomes even more important to your team’s efficiency. Nothing kills team chemistry and collaboration quicker than having tasks done “half-way” only because another teammate thought they only had to scope out a project, and not actually supply mocks or a rough draft.
Coming up with a Definition of Done is about the bigger picture organizational process of your team. By looking at projects as a collaborative effort instead of dividing responsibilities among different departments or one leader, you encourage the communication and transparency that’s necessary for Agile.
This is why creating a Definition of Done should be a starting point for Scrum teams. Your organization should essentially have a checklist of specific criteria and requirements that need to be fulfilled before the user story is done. However, the definition will likely different from organization to organization based on the size of the teams, different fulfilled roles, and different project requirements.
Criteria to Consider When Defining Done
- Prioritizing tasks – Having an order and process in place should be a prerequisite for defining done. This means having a set expectation for every time a task moves throughout your Kanban flow, whether something is selected for development or in code review. Also, this includes deciding whether a Definition of Done should just be attributed to user stories, or features and epics as well.
- Including testing – Testing is often the most overlooked step. Is more manual or automated testing needed for this particular project? Are you using regression tests throughout development or just at the very end? Have you tested across multiple browsers? What processes do you have in place for analyzing risk and evaluating security?
- Involving every role – If your developers have a different Definition of Done than your testers, for example, projects aren’t going to be done by everyone’s standard. This also includes product owners, project managers, scrum masters, designers, automation engineers, QA, or any other role. Furthermore, the definition should not be prescribed by one team member, but instead agreed upon by everyone.
- Coming up with a timeline – How many iterations are you striving to make throughout the day? How many are you committing to at the end of the day? What are the goals during your sprints? How do you keep track of this and what happens if a task is not completed in time?
- Ask what makes the process complete – Is it done when the product goes through a last round of testing, is it done after a last once-over by the product owner, or is it when it’s released to the end user? Having an end point is just as important as having a designated place to start.
- Document the definition – Have the information easily accessible for people to reference, even if it’s printed out as a checklist. This way, everyone can double-check before they move a task into “done.” Additionally, in the same way, that Agile is adaptable, your Definition of Done should be, too. Make sure to return to the document and reassess processes that need to be adjusted according to changing requirements.
How do you decide when a project is “done”? Share your thoughts in our comments!
