Dino Cajic explaining the Definition of Done in Software Development

  • Project Manager
  • Development Manager
  • UI/UX Engineer
  • Lead Software Developer
  • Software Developer
  • QA Engineer
  • Client


Before you can start gathering requirements from a client, there is a checklist of items that need to be in place. The checklist is there to help you get setup with the project so that you’re running instead of crawling. The various roles are assigned each task so that there’s no ambiguity.

  • Project setup in Confluence? Business Analyst. The BA sets up the Confluence project or another form of centralized knowledge repository. This is where all of the documentation and requirements will live.
  • Project setup in Jira? Business Analyst. The BA sets up the Jira board since they will create the tasks as they are gathering requirements.
  • Client Jira board setup? Business Analyst. If the client needs detailed exposure, sometimes an external Jira board is warranted. I’ve seen other individuals use Smartsheets to replicate tasks from the internal board so that the client knows where they’re at in the process.
  • Project Repo initialized? Lead Software Developer. Do you host your code on GitHub, BitBucket? This is the time to initialize the repository.
  • Staging and Production Environments Initialized? Lead Software Developer. If you’re certain that you know which stack you’ll be using during development, now’s the time to initialize the staging and production environments. Otherwise, you’ll have to initialize these environments during the requirements gathering phase.
  • Deployment Scripts initialized and initial code pushed? Lead Software Developer. Same line of thinking as above. If you’re confident with the stack used, this will be the time to setup the deployment scripts and push your code to the staging environment; if the production environment is fresh, initialize it too.

Definition of Ready

Now that you have some preconditions out of the way, it’s time to start working on the Definition of Ready. This is where an experienced Business Analyst is helpful to have. During the many client calls that the BA will have, he or she will extract the necessary requirements and transfer them over into Jira and Confluence. The following checklist should be completed for each feature.

  • Story is feasible? Business Analyst, Lead Software Developer
  • Story is testable? Business Analyst, QA Engineer
  • Client team member that will accept the story is identified. Business Analyst, Project Manager
  • Issue created in Jira? Business Analyst
  • Jira Epic created (if it doesn’t exist) and assigned to an issue? Business Analyst
  • Story added to issue? Business Analyst
  • Acceptance Criteria created and added to issue? Business Analyst
  • Functional Requirements Document created (if it doesn’t exist) and linked to issue. Business Analyst. Some BA’s create the FRD’s before they start working on issues.
  • Release Date, Jira Epic, Client Contact, Project Manager, BA, Dev Lead, and UI/UX Engineers added to FRD? Business Analyst
  • Functional Requirements Document Overview created? Business Analyst
  • Supporting links and/or documents added to FRD? Business Analyst. This might be the clients attempt at showing you their vision of the feature outlined in a Powerpoint presentation.
  • Technical Requirements outlined? Business Analyst. This is the meat of the FRD and where an experienced BA shines brightest. The Technical Requirements should be completed fully without the need for the developer to ever leave this one FRD.
  • Functional Requirements Document and Acceptance Criteria sent to client? Business Analyst. It’s better to have a client sign-off early so that when the client asks for new features, you can point clearly to the FRD that they signed off on, which is of course more detailed then the SOW.
  • Issue replicated in client’s Jira board? Business Analyst. Optional, but some clients love the transparency. Make sure that this is factored into your cost.
  • Developer identified and added to the issue? Lead Software Developer, Developer
  • Story point estimation added to issue? Lead Software Developer, Developer
  • Hour estimation added to issue? Lead Developer, Developer. This is optional but makes for good practice in honing down your estimation.
  • Team members have a good idea of how to demo the user story? Dev Lead, Developer, Project Manager. That’s right. Before any code is written, the Project Manager should know what to expect when demoing the feature to the client.
  • Backlog Groomed and Sprints Defined? Lead Developer, Developer, Project Manager. After everything is created, it’s time to tackle the tasks and organize them into sprints. The BA will have grouped the tasks closely prior to this so that going through the backlog should be relatively easy.

Definition of Done (DoD) — Developer

The first Done Definition that we’ll define (say that 3 times fast) is the Developer’s DoD. It just makes sense to have checklists for each instance, so we’ll continue with a brand new Developer DoD Checklist. It’s broken down to the task level and it involves more than just the developer.

  • Task moved from the “ToDo” column to the “In Progress” column in the Client’s Jira Board? Project Manager. It doesn’t have to be done simultaneously, but as long as the boards match at the end of the day, it should be good enough. Side note, the external Jira board can make you or break you. If there’s a disconnect, the client will lose confidence and will start getting frustrated. Make sure that the board is up to date at least a couple of days before you speak with them.
  • Code produced based on requirements? Developer
  • Code pushed to the repo and pull request submitted to the lead developer? Developer
  • Hours logged? Developer
  • Code reviewed and PR approved? Lead Developer
  • Feature branch merged into development branch? Developer
  • Code pushed to staging environment? Developer or Lead Developer
  • Task moved from “In Progress” to “Internal QA?” Developer
  • Issue moved from “In Progress” to “Internal QA” on the client board? Project Manager
  • Time logged for deployment process? Developer and/or Lead Developer

Definition of Done (DoD) — QA Engineer

The task has moved its way into the Internal QA column. This column references the Staging environment testing that needs to be done before the code can be merged into a production environment.

  • Unit tests written? QA Engineer. Optional. Is the client willing to pay for it? Does the client want to pay for full Test-Driven-Development (TDD)? If the answer is yes to the second one, this step is removed. Having any sort of unit tests is better than none and sometimes it just makes sense to do them after the fact. If you’re interested about Unit Tests, and when they shouldn’t be incorporated, you can read my article titled When Unit Tests Become the Wrong Choice.
  • Pass or Fail comments added to issue? QA Engineer
  • If the issue passed QA, task moved from “Internal QA” to “External QA?” QA Engineer. The external QA is not handled by the QA engineer.
  • If the issues fails QA, task moved form “Internal QA” to “In-Progress” or “QA Rejected” which is synonymous with “In Progress?” QA Engineer
  • QA hours logged? QA Engineer

Definition of Done (DoD) — Lead Software Developer

The Lead Dev is up next, which realistically only has one task: deploy to production. However, there are other tasks that need to occur prior to deployment.

  • Issue tested on staging environment? Client. This is the client’s responsibility. If they sign off on it, all new modifications require a new SOW.
  • Pass or fail comments added to issue with screenshots in external Jira board? Client
  • If successful, Issue moved from External QA to Done in client’s board? Client. This is important if the client is willing to participate. They are the ones that move the issue to Done when they feel like it’s truly complete. Any attempts to sneak in extra work should be addressed and a new SOW created.
  • If rejected, issue moved from External QA to In Progress in client’s board? Client. If the client finds an issue with the items produced, they can reject the issue. There are tasks that are setup tasks that should not be presented to the client, such as migration file creation. The only issues that the client should see are the stories that they worked on.
  • Client comments evaluated and added to internal board’s issue (if necessary)? Project Manager. If the client leaves any comments on the task, those comments should be copied over to the internal Jira board, cleaned up of course.
  • If Client Approved, issue moved from External QA to Done in internal Jira board? Project Manager
  • If Client Rejected, issue moved from External QA to In Progress in internal Jira board? Project Manager
  • Remaining hours left in issue set to zero? Project Manager
  • Code pushed to production environment on release date? Lead Developer. There should be a separate task for Lead Developers to log their hours during production pushes. You don’t want to divide those up on an individual basis since it can get excessive.

Definition of Done (DoD) — Client

That’s right, the client. It’s not done until the client signs off on everything. There are still a couple of tasks that they should do.

  • Issue approved in production environment? Client. This doesn’t have to be formal. As long as there’s no complaints coming from the client, you can feel comfortable that it has passed. If it’s something that can be quickly smoke tested, it wouldn’t hurt for the PM to quickly smoke test the sites and verify that the core functionality is still operational.
  • Client rejects issue in production environment. Contacts PM to report bug in production environment. This is where the fun starts. If there is an issue in production, the bug has to be evaluated and either fixed right away or a new SOW created.

Definition of Done (DoD) — Project Manager

There’s still one more task left to do and that is to close the issue for good. Sometimes it’s enough for the issue to reach the Done column for it to be marked as complete. Other times, the PM wants to explicitly mark the issue as Closed.

Done Done

We’ve gone through quite a journey. Make sure that you client understands the various definitions of “Done” within your process. This article is a good starting point. Tweak it for your environment and never be caught saying, “well I know I said it was done, but it wasn’t really done.”

Leave a Reply