The process that we follow for each sprint is shown below, this also shapes our scrum board for sprints as well. Each box represents a column on scrum board while to move an issue from one box to another requires the “Quality Gateway” between those boxes to be met.
Each stage here represent a column on a team’s scrum board. These can differ based on client or team needs. It can also change based on the project type itself, yet, this creates a good basis in order to follow a common way of working.
- Backlog: The issues are not required to be groomed here. They can represent a huge deliverable or a small bug at this point. Issues might be prioritized or not. Grooming and planning meetings are done in order to refine these issues.
- To Do: These are the issues that teams agreed on finishing within a sprint. These issues have clear goals, prioritization, estimation, well written description and all the other required things from the team in order to start the development. Issues here should meet “Definition of Ready”
- In Progress: Here, all the tasks are being developed by a member or members of the team. In development, developer should consider all the things written inside the issue, and should aim to satisfy the acceptance criteria.
- In Review / QA: This part is where PO or QA tester takes an issue that is marked by a developer as “Development is finished” and tests it against the acceptance criteria and other test cases.
- Done: If an issue is marked as “Done”, this means that it will be delivered with the next increment and the feature is completed. Issues here should meet “Definition of Done”
In order to help each member of the team, we have some “Quality Gateways” that we highly suggests teams to use in order to increase the product quality as well as saving teams time for not going back and forth between the stages.
Quality Gateway 1: The first “Quality Gateway” is there in order to help developers understand everything about the issue. There are things to be taken into consideration before taking any issue to the next sprint, and they represent this QG.
- Issue should be well groomed with clear acceptance criteria and story (if applicable, it can be a bug or technical debt issue, thus, it might not have story)
- Estimation should have been done by the team.
- Priority should be set.
- Should satisfy “Definition of Ready”
- Impact analysis should be done.
Quality Gateway 2: This gateway is really similar to the QG1 where all the things that were mentioned there should be reconsidered. Other than those we recommend:
- Tasks should have been created by the team. (if applicable)
- Issue picked up by a developer
Quality Gateway 3: This part is supported with the CI pipelines for achieving the quality, yet, it still needs some investigation by the team itself.
- Unit tests are executed and they pass (if applicable)
- Merge request is submitted.
- Automated build succeeds.
- Code review is done.
- Static code analysis is done. (if applicable)
Quality Gateway 4: This gateway decides if the feature should be in the next increment. Here PO and QA testers checks the issues and sees if it satisfies the requirements.
- Acceptance criteria is checked.
- QA tests are executed and they pass.