ISO 9001 quality management system is directly mapped to a Scrum framework in an agile software development environment. How? Let’s see the ISO requirements and the corresponding Scrum practices that we follow.
ISO recommends starting with a quality manual for software development. This will ensure and improve quality in your software development life cycle and monitor client satisfaction. Once you have the quality manual that describes the process for software development, the next step is to implement it. The implementation uses the Scrum framework. In Scrum, we have three main roles- product owner, Scrum master, and the Scrum team. They are responsible for implementing the process. ISO also recommends developing a hierarchy that will help to improve the overall process performance. ISO focuses on continual improvement and so do Scrum. ISO recommends all QMS to be planned, implemented, measured, and improved. Scrum also works on similar lines – sprint plan, sprint execution, sprint review, and sprint retrospective.
The table below maps all required ISO clauses for software development to the corresponding Scrum practice.
|
Sl. No |
ISO Clause |
Requirement |
Scrum Practices |
|
1 |
5.2 – Customer focus | Ensure customer requirements are met to enhance customer satisfaction. | Product backlog creation and grooming. |
|
2 |
5.5.1 – Responsibility and authority | Responsibilities and authorities are defined. | Different roles in the Scrum – product owner, Scrum master, and Scrum team. |
|
3 |
5.5.3 – Internal communication | Ensure that appropriate communication processes are established. | Daily stand-up meetings, product backlog grooming, sprint review, and sprint retrospectives. |
|
4 |
7.1 – Planning of product realization | Planning and development of the product. | Product backlog creation, sprint planning, sprint backlog creation, and user stories. |
|
5 |
7.2.1 – Determination of requirements | Ensure Requirements are captured properly. | User stories with acceptance criteria. |
|
6 |
7.2.2 – Review of requirements | Ensure that a review of requirements is done. | Architectural and business review of user stories before estimation. |
|
7 |
7.2.3 – Customer Communication | Customer communication regarding requirements, bugs, etc. | Daily standup meeting. |
|
8 |
7.3.1 – Design and development planning | Plan and control the design and development of the product. | Sprint planning, estimation of user stories, and assigning points. |
|
9 |
7.3.2 – Design and development inputs | Inputs related to product requirements shall be determined and records maintained. | User stories with acceptance criteria. |
|
10 |
7.3.3 – Design and development outputs | Outputs of design and development shall be in a form suitable for verification against the design and development input and shall be approved before release. | Sprint review |
|
11 |
7.3.4 – Design and development review | At suitable stages, systematic reviews of design and development shall be performed following planned arrangements. | Sprint retrospective |
|
12 |
7.3.5 – Design and development verification | Verification shall be performed following planned arrangements to ensure that the design and development outputs have met the design and development input requirements. | Testing – Sprint execution |
|
13 |
7.3.6 – Design and development validation | Design and development validation shall be performed according to planned arrangements to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use, where known. |
UAT- Sprint execution |
|
14 |
7.3.7 – Control of design and development changes | Design and development changes shall be identified and records maintained. | Change management, sprint planning, sprint review |
|
15 |
8.2.1 – Customer satisfaction | The organization monitors information related to customer perception to check whether the organization has met the customer requirements. |
Sprint review |
|
16 |
8.2.4 – Monitoring and measurement of product | The organization shall monitor and measure the characteristics of the product to verify that product requirements have been met. | Sprint review, daily standup meeting, sprint planning, burn down charts. |
|
17 |
8.3 – Control of nonconforming product | The organization shall ensure that a product that does not conform to product requirements is identified and controlled to prevent its unintended use or delivery. | Testing, sprint review |
|
18 |
8.4 – Analysis of data | The organization shall determine, collect, and analyze appropriate data to demonstrate the suitability and effectiveness of the quality management system and to evaluate where continual improvement of the effectiveness of the quality management system can be made. | Burn down charts, sprint retrospective |
|
19 |
8.5.1 – Continual Improvement | The organization shall continually improve the effectiveness of the quality management system. | Sprint retrospective, sprint review |
|
20 |
8.5.2 – Corrective Action | The organization shall take action to eliminate the causes of nonconformities to prevent recurrence. | Root cause analysis, sprint retrospective |
|
21 |
8.5.3 – Preventive Action | The organization shall determine action to eliminate the causes of potential nonconformities to prevent their occurrence. | Root cause analysis, sprint retrospective, and product backlog grooming. |
ISO 9001 and Scrum are not two different things. They both try to improve the software development process. And a company that wants to delight customers and improve on quality needs to adopt both.
