Make sure you know what makes your software complete.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
In Agile, every user story should have clearly defined Doneness or acceptance criteria. There are two important parts while defining the Doneness criteria; one is functional, and another one is non-functional. In most cases, people will define the functional acceptance criteria very well and do not give much importance to non-functional doneness checklist.
For ensuring software quality in all aspects, the doneness criteria should be achieved from both functional and non-functional aspects. To ensure non-functional doneness criteria is also taken care, we must define the checklist and ensure it is followed for all user stories.
Reaching your pinnacle needs a lot of discipline. It does not come easily. Achieving continuous software quality is again comes with lots of dedication and discipline. To get the desired result in software quality every time, we must follow the processes religiously, retrospect, and improve continuously.
One of such processes that helped us is the “Doneness checklist.” It is mainly, a list of best practices that we learned and agreed to follow for every user story in a release.
It basically contains the below list of items for each user story and we expect the user story owner to sign off all of them mandatorily.
- Requirement Analysis – Finalize acceptance criteria
- Technical Design & review
- Code review
- Cross-cutting concerns review –caching, transaction, security
- Database design & review
- Performance review
- Security review – XSS validation
- Initial/upgrade data script
- Accessibility check
- Browser test
- Build number update
I like to consider these checklist items hygiene factors of software development practices, and they must be followed without fail. To ensure they are followed, I suggest two methods:
- Create these as tasks for each user story
- Create a checklist document and get sign off from the user story owners
We follow both options. Some of the basic ones, like reviews, are created as part of the user story tasks list. This way user story owner has to complete these tasks as part of the user story. The story will be accepted only if these tasks are completed.
Though it sounds like too many tasks for every user story, a very useful checklist ensures the quality of each user story.
Some of the benefits with this doneness checklist are as follows
The code quality is assured by ensuring there is proper design for every user story. In Agile, some people think that no documentation is required, but but is just a myth. We must do incremental design for every user story and ensure quick diagrams are created for them. It is not really required to create a very detailed low-level design document. It may be a just brainstorming whiteboard design captured and uploaded to the user story. This is achieved through a design review checklist in our process. Every user story in a sprint will contain a design review task.
This checklist will ensure there is a focus on incremental design for each user story and eventually for the full release.
For achieving the code quality, it is important to do a technical group code review for each user story. In this review, the below items are validated:
- Coding standards
- Security best practices
- The design is robust and implemented as per initial design
- All business rules are implemented to meet the acceptance criteria.
- Proper test cases are written based on code written by developers
There are many advantages of doing the group code review
- Code quality is improved as we get different views/ideas from senior to junior people in the team.
- Cross-pollination – Domain knowledge and technical knowledge are cross-pollinated between all team members. This is a very important process if the team is working on product development, as it helps to share domain knowledge across the teams.
- QA will get a chance to validate their test cases against the code written. It is a kind of white box testing discussion
- No technical debt
It is also important to validate some of the cross-cutting concerns like caching, security and Transaction required or not as part of the code review process.
As part of this, we must thoroughly check the below items
- Coding best practices for SQL Stored procedure
When a feature is developed then it is important that we give importance to the data as well. The data that is required initially in the table is called the initial data script. If the feature is already in production and new feature change requires data change then it is called upgrade data script.
If these are not taken care during the development and test process, there are high chances that we will get production tickets.
All our test environments should follow the same process used for production deployment. This way these initial/upgrade data scripts are also tested thoroughly in our test environment.
Build Number Update
To summarize, a Doneness checklist is very useful to build the process that will ensure software quality all the time. It is a boon for software teams, especially for enterprise level software and big teams.
Opinions expressed by DZone contributors are their own.