Chronicles of a Scrum master #16 : Definition of Done (DoD) Part 2

Note : This is a continuation of my Definition of Done (DoD) Part 1 here.

3. Quality

The important assessment of a story after its development or work that needs be done is completed (may not be Done yet) is the quality of the work that is produced. This is usually performed by the QA (Quality Assurance) engineer who must be equipped with the right knowledge to test the product from end to end (even if its sometimes outside the product e.g. Integration to other critical systems).

The quality that needs to be assessed includes the following :

  • Compliant to the acceptance criteria defined in the user story (additional points if it addresses some aspects that may have been missed out in the acceptance criteria)
  • The outcome of the story does not suffer from any critical bugs or defects and performs well (e.g. system performance such as page loading etc)
  • The story results in a delightful user experience, which is both intuitive, straight forward and simple to be used
  • The visual aspect of the story (if any) is attractive and appealing to the desired audience and invokes a sense of understanding of why it is needed as well as pleases the audience.
  • In the current world where everything runs on the cloud and Internet, the security adherence and compliance with relevant regulations and standards must be followed clearly and closely to ensure no security breaches.
  • In the end, after all the above, the outcome of the story must meet the Definition of Done (in some teams it can be SIT or UAT sign off and in others, ready for Production).

4. Other non-functional requirement

One of the many forgotten and sometimes ignored aspects of a story when it is being developed are the Non-functional requirement (NFR) aspect.
Sometimes can be either due to the inexperience of the team dealing with such requirements. To experienced individuals, this can sometimes be a given but for those who doesn’t have such experiences before may overlook the NFR aspects.

The non-functional requirements include several factors that encompasses usability, performance, security, scalability and compatibility requirements. They can be also used to define the overall quality and characteristics that is being developed as part of the story.

This requirements are detailed more below :

  1. Usability: NFRs that relate to the user experience and user interface that enables the interaction between the user and outcome of the story. Usually this is expressed in terms of ease of use, simplicity and user-friendliness, such as the layout and design of the user interface, the clarity of instructions, and the speed of response.
  2. Performance: NFRs that relate to the speed and efficiency of the product, such as the response time of the system, the volume of data that can be processed, and the availability of the system.
  3. Security: NFRs that relate to the security and integrity of the product, such as the protection of sensitive data, the prevention of unauthorized access, and the ability to detect and respond to security threats.
  4. Scalability: NFRs that relate to the ability of the product to handle increased usage or workload, such as the ability to support a large number of users or to handle a large volume of data.
  5. Compatibility: NFRs that relate to the ability of the product to work with other systems or technologies, such as the ability to integrate with other software applications or to support different hardware platforms.

By including NFRs in user stories, development teams can ensure that the product meets the desired level of overall quality and performance, in addition to the specific functional requirements. This can help to improve the user experience and increase customer satisfaction.

In summary, I hoped this article has helped you better understand the definition of done and how it encompasses multiple aspects of the story from understanding the requirements to its completion.

Thank you for reading this and please stay tuned for my next article 🙂

Agile Scrum master

Chronicles of a Scrum master #17 : Technical debt and Support tickets

In agile way of working, technical debt is still present as the team goes about completing stories based on definition of done. What then exactly is technical debt ? This is the accumulation of previous known anomalies, which were not discovered previously before release. It can be in the form of bugs, design changes, code […]

Read More
Agile Scrum master

Chronicles of a Scrum master #15 : Definition of Done (DoD) Part 1

What is a story that is considered done in a sprint ? Each scrum team may have their own version of the Definition of Done (DoD) for each story as long as they agree on the common concept as a whole (from product owner, business analyst to scrum master, developers and testers. It is essentially […]

Read More
Agile Scrum master

Dec 31 2022 – End of year Scrum master chronicles : Agile implementations

Alas, we are reaching the end of 2022 in a matter of days 🙂 Here in this last post of my 2022 scrum master experience, I would like to thank all my fellow readers and wishing everyone a Happy New Year in advance and may your new year resolutions be made real. Going back through […]

Read More