Table of content
- User story double-checked
- Code is readable and clean
- Check if changes can affect several components
- Check if changes can affect several types of users
- No errors in the console
- Internationalization: all languages are filled
- Must be responsive
- Must be accessible
- HTML and CSS are valid
- Functionality tested in multiple browsers
- New metrics if necessary
- Code is bug-free
- Unit tests covering most of the branches and with meaningful expects
- End-to-end tests are passing
- Integration tests are passing
- Performance tests are passing
- Security standards have been met
- Any configuration, build changes, or model changes are documented
- Documentation: Confluence / Swagger / StoryBook / Readme
- Screenshot for the sprint demo
- Code review and functionality tested by team members
- Approved by QA
- Approved by stakeholders (customer, manager, product owner)
- Pipeline or build are passing
After a few years of being a software developer, I want to make a list of some tips and examples that you can include in the definition of done.
I will keep an eye on the comments to add new items if necessary.
Keep in mind that the best DoD is that one that has been agreed upon across the team. The order is meant to be logical from a dev perspective, and some of them are front end specific:
User story double-checked
It could seem obvious but is not. Read the user story after you think everything is done, in case you have forgotten something.
Code is readable and clean
It would be also well-formatted, complying with the style guide used by the team.
Check if changes can affect several components
Try not to break other functionalities while developing new features. If the changes affect other parts, validate all of them.
Check if changes can affect several types of users
It is common to have different roles (administrators, consumers, publishers, etc). Test the functionality against all of them.
No errors in the console
Sometimes everything seems to be ok, but there are still some errors in the console. If you are working in the frontend, maybe you can try a javascript error notifier chrome extension.
Internationalization: all languages are filled
Be sure to check that all translations are ok and every i18n file contains the right language.
Must be responsive
If the feature requires some new markup, it has to be responsive. Check also that there is no horizontal overflow. I wrote an article just about this.
Must be accessible
Always keep in mind that what you do should be accessible and meet the WCAG standard.
HTML and CSS are valid
Validate the HTML and CSS rules. You can use the W3C Markup Validation Service.
Functionality tested in multiple browsers
Test always at least two browsers. Knowing the most used browsers for your app/website should help to run specific tests in that ones.
New metrics if necessary
Sometimes we need to measure how much value is being delivered to the user.
Code is bug-free
Try to break the new feature. Test for basic and non-basic functionality issues. What if you fill forms with empty inputs, incorrect types, or too long texts? Also, if I'm developing a new endpoint and, I don't receive all the data? (try to use schema validations).
Unit tests covering most of the branches and with meaningful expects
Try to cover at least 85% of the lines, and the majority of the branches. Expects have to make sense, and tests descriptions as well.
End-to-end tests are passing
In our team we use Cypress, and sometimes it is required to make a new e2e test for some parts.
Integration tests are passing
Very important if we don't want to break the application as a whole.
Performance tests are passing
Very few projects that I've worked on had performance tests. But they are important and this could apply in some cases. Artillery saved my life in the past.
Security standards have been met
Ohhh this is hard but always having in mind security could save yours. We use SonarQube and Kiuwan.
Any configuration, build changes, or model changes are documented
Maybe this user story requires doing something after everything is deployed. Or maybe there is a model change that has to be notified to other teams that depend on us. We use RFCs, but the user story should reflect those situations.
Documentation: Confluence / Swagger / StoryBook / Readme
It depends on the side you are working on, but documentation is your ally. Also meet the backend and frontend standards like Swagger, Storybook, or a basic Readme file.
Screenshot for the sprint demo
At the end of every sprint, you should be doing a demo to show and review new functionalities. Once you have everything ready, just make a screenshot before continuing with another user story.
Code review and functionality tested by team members
So you came through all of that, well done. Now leave other team members, ideally, more than two, review your work. Three persons think more and better than just one.
Approved by QA
If you can have a QA team in charge of that part, perfect. They should give you the ok.
Approved by stakeholders (customer, manager, product owner)
I've been in some teams in which ones the PO had to give his approval to continue.
Pipeline or build are passing
And if everything seems ready, just be sure the pipeline is passing and there is no problem with the build process as well.
So these are some ideas that maybe can fit in your definition of done. What do you think? What is yours?
I hope you have learned something new. If you think this might help other people, please hit the like button so that others can read it. ❤️
If you have any thoughts or questions, feel free to leave a comment!
