This is one of my absolute favorite topics to discuss in software development: Definition of Done in Software Development. While my approach is not fully flushed out for every environment, it’s gets you 90% there. This will help with creating a team and setting expectations. When is each team member actually done during the software development lifecycle? Have you found yourself saying, “well I know I said it was done, but it’s not really done?”
Before we can start looking at each individual’s Done definition, we have to outline the members involved.
- Business Analyst
- Project Manager
- Development Manager
- UI/UX Engineer
- Lead Software Developer
- Software Developer
- QA Engineer
- Client
Can we start with our definition building now? We could, but we would be missing defining a large section of the Software Development Process: the Definition of Ready and even the Preconditions that exist prior to that.
Preconditions
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.
- Initial Client Call complete? Business Analyst, Development Manager. During the initial call, small requirements are gathered so that you know how to prepare for the project ahead. If the customer is looking for a mobile app vs a web-app, this is the time to ask those questions.
- 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 created and is clear? Business Analyst, Client
- 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 Internal Jira Board? 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
As far as the developer is concerned, he or she is done with their portion of the work. They go back to the top of the list and start over.
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.
- Story tested based on the acceptance criteria? QA Engineer
- 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
The QA Engineer has exhausted what they can do and is finished with testing as far as they’re concerned.
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 moved from “Internal QA” to “External QA” column in the client board? Project Manager. This tells the client that the issue passed internal QA testing and should now be tested by them. This is where you’ll run into most issues with keeping the project timeline in check and the sprints moving smoothly. The client needs to understand that they need to put in some work as well. If it’s a recurring issue, and the client does not do their share of testing, then having the External QA column might be a waste. The Project Manager is there to help whip the client into shape.
- 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.
The Lead Developer is done at this point since they pushed the code to the production environment. There are still a few tasks left.
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.
- Issues tested in production environment? Client. Now that the code is live on the production environment, it helps to have the client test their environment and report on any bugs that might have been found.
- 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.
The client is done.
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.”