Articles

In today's dynamic project management landscape, the role of a Scrum Master is pivotal to ensuring the success of Agile teams. The Scrum Master is not only a facilitator but also a coach, mentor, and leader, guiding the team towards effective Scrum practices. To excel in this multifaceted role, hands-on training is essential, and SCRUMstudy through its network of approved Authorized Training Partners offers comprehensive Scrum Master classes that blend theoretical knowledge with practical experience.

These classes go beyond traditional lectures, incorporating interactive activities, real-world scenarios, and collaborative exercises. Participants engage in role-playing, simulations, and group discussions, allowing them to apply Scrum principles in a controlled, risk-free setting. This experiential approach ensures that learners can translate classroom knowledge into actionable skills in their professional environments.

Moreover, SCRUMstudy's approved institution's experienced trainers bring a wealth of industry knowledge and insights to the classroom. These experts share their personal experiences, best practices, and tips for overcoming obstacles, providing valuable guidance that textbooks alone cannot offer. Learners benefit from direct interaction with seasoned professionals, gaining a deeper appreciation of the nuances and subtleties of effective Scrum Mastery.

SCRUMstudy-approved training organization's classes for Scrum Masters offer a holistic learning experience that blends theory with practice. By participating in these classes, aspiring Scrum Masters can develop the confidence and competence needed to lead their teams successfully, foster a collaborative work environment, and ensure the successful delivery of high-quality projects.

Scrum certification holds significant acceptance in industries that prioritize agile methodologies for project management. It validates professionals' understanding and proficiency in Scrum practices, making them valuable assets in organizations seeking to enhance efficiency, adaptability, and collaboration within teams. Employers recognize Scrum certification as evidence of an individual's commitment to continuous improvement and their ability to lead teams in delivering high-quality products efficiently. As Scrum continues to gain traction across various sectors, certified practitioners play a crucial role in driving innovation and achieving business objectives through agile principles.

The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project. The required features are described in the form of User Stories. User Stories are specific requirements outlined by relevant business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria, which are the objective components by which a User Story’s functionality is judged.

A clear definition of Done is critical because it helps clarify requirements and allows the team to adhere to quality norms. It also helps the team think from the user’s perspective when working on User Stories. Acceptance Criteria are developed by the Product Owner according to his or her understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members and their agreement is sought. Acceptance Criteria should explicitly outline the objective conditions that User Stories must satisfy for them to be accepted by the Product Owner.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject deliverables. If deliverables are accepted by the Product Owner, then the User Story is considered ‘Done’.

Although Acceptance Criteria are unique to each User Story, they are not a substitute for a requirements list. It is important for a Product Owner to note that User Stories that fulfill most, but not all, Acceptance Criteria cannot be accepted as Done. Scrum projects operate in Time-boxed Sprints, with a dedicated Sprint Backlog for each Sprint. Often, the last bit of work might be the most complicated part of a User Story and might take longer than expected. If incomplete User Stories were given partial credit for being Done and carried over to the next Sprint, then the progress of the subsequent Sprint could be disrupted. Therefore, the Done status is black and white. A User Story can only be either Done or not Done.

Let us now look at the key differences between “Done Criteria” and “Acceptance Criteria.” While Acceptance Criteria are unique for individual User Stories, Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. General Done Criteria could include any of the following:

• Reviewed by other team members
• Completed unit testing of the User Story
• Completion of quality assurance tests
• Completion of all documentation related to the User Story
• All issues are fixed
• Successful demonstration to business stakeholders and/or business representatives

As with the Acceptance Criteria, all conditions of the Done Criteria must be satisfied for the User Story to be considered Done.

The Scrum Team should use a checklist of the general Done Criteria to ensure a task is finished and the result meets the Definition of Done (DoD). A clear Definition of Done is critical because it helps remove ambiguity and allows the team to adhere to required quality norms. The required records and data to comply with the project’s documentation requirements can be generated as the team proceeds through Sprints and Releases.

The inclusion of activities such as holding review meetings and writing design documents can help ensure compliance with internal and external quality standards. The basic principles of Scrum such as short iterations, incremental building, customer involvement, adaptation to changing requirements, and constantly adjusting scope, time, and cost within the project will still apply.

Acceptance Criteria are the objective components by which a User Story’s functionality is judged and are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. Acceptance Criteria should outline the conditions that User Stories must satisfy. At the end of each Sprint, the Product Owner uses these Criteria to verify the completed deliverables and can either accept or reject individual deliverables and their associated user stories. Good acceptance criteria should include the characteristic of Usability, Performance, Functionality, Error handling and Stress tests

Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project. It is a challenge for Scrum Product Owner to come up with and describe the boundaries of User Stories based on limited information.

Product Owner’s decision making is based on ways looking for safe solutions (principles of satisficing), the information and the time they have to make decisions. That is, their decision-making strategy attempts to meet an acceptability threshold rather than finding the best option available. They do not stick to make optimized decisions.

Scrum projects operate in Time-boxed Sprints and due to time constraints it is not always possible to provide a detailed list of criteria that will cover the User story as a whole. Therefore, Product Owner comes up with a list that is good enough to move the sprint ahead.

Product Owner begins conversations with the customer and stakeholders for outlining specific requirements as they pertain to the proposed product or service and begin the search for the optimal list of Acceptance Criteria. But in reality, the Product Owner identifies a list of criteria which is highly visible and not comprehensive or exhaustive. Once the list is identified, the product owner discusses them with the team. Review begins with alternatives, differing a little from the current choice of list, along with the team and it continues until the product owner identifies an alternative that meets acceptable level of performance.

Constituting an exhaustive list for Acceptance Criteria is not mandatory but they should be sufficient to move the sprint forward. Acceptance Criteria are limited by time and they do not add internal value to the future product.

Role of Acceptance Criteria in maintaining quality is critical and needs to be clearly understood by the team members. User Stories should be able to ignite ideas in team members so that presence of a detailed list of criteria covering all aspects is no longer being required.

The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project. The required features are described in the form of User Stories. User Stories are specific requirements outlined by various business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria (also referred to as “Acceptance Criteria”), which are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members, and their agreement is sought. Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy. Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject individual deliverables and their associated User Stories. If deliverables are accepted by the Product Owner, then the User Story is considered Done. A clear definition of Done is critical because it helps clarify requirements and allows the team to adhere to quality norms. It also helps the team think from the user’s perspective when working with User Stories.

User Stories corresponding to rejected deliverables are added back to the Updated Prioritized Product Backlog during Refine Prioritized Product Backlog Process, to be completed in future Sprints. The rejection of few individual deliverables and their corresponding User Stories is not a rejection of the final product or product increment. The product or product increment could be potentially shippable even if a few User Stories are rejected.

Writing Acceptance Criteria

Acceptance Criteria are unique to each User Story and are not a substitute for a requirements list.

It is important for a Product Owner to note that User Stories that fulfill most, but not all, Acceptance Criteria cannot be accepted as Done. Scrum projects operate in Time-boxed Sprints, with a dedicated Sprint Backlog for each Sprint. Often, the last bit of work might be the most complicated part of a User Story and might take longer than expected. If incomplete User Stories were given partial credit for being Done and carried over to the next Sprint, then the progress of the subsequent Sprint could be disrupted. Therefore, the Done status is black and white. A User Story can only be either Done or not Done.

Minimum Acceptance Criteria

A higher level business unit may announce mandatory minimum Acceptance Criteria, which then become part of the Acceptance Criteria for any User Story for that business unit. Any functionality defined by the business unit must satisfy these minimum Acceptance Criteria, if it is to be accepted by the respective Product Owner. The introduction of this Acceptance Criteria may lead to a cascading set of Acceptance Criteria for the portfolio, program, and project (see the figure below). The overall quality standards, guidelines, and templates for an entire portfolio are set by the Portfolio Product Owner while the minimum Acceptance Criteria at the program level are set by the Program Product Owner. Thus the Acceptance Criteria for a User Story in a project will implicitly include all the minimum Acceptance Criteria from the higher levels, as applicable.

Once the minimum Acceptance Criteria are defined, such criteria may then be documented in the Scrum Guidance Body documents and referred to by Scrum Teams as required.

Definition of Done

There is one key difference between “Done Criteria” and “Acceptance Criteria”. While Acceptance Criteria are unique for individual User Stories, Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. General Done Criteria could include any of the following:

• Reviewed by other team members
• Completed unit testing of the User Story
• Completion of quality assurance tests
• Completion of all documentation related to the User Story
• All issues are fixed
• Successful demonstration to business stakeholders/business representatives

As with the Acceptance Criteria, all conditions of the Done Criteria must be satisfied for the User Story to be considered Done.

The Scrum Team should use a checklist of the general Done Criteria to ensure a task is finished and the result meets the Definition of Done (DoD). A clear Definition of Done is critical because it helps remove ambiguity and allows the team to adhere to required quality norms. The definition of Done is typically determined and documented by the Scrum Guidance Body.

The required records and data to comply with the project’s documentation requirements can be generated as the team proceeds through Sprints and Releases.

The inclusion of activities such as holding review meetings and writing design documents can help ensure compliance with internal and external quality standards. The basic principles of Scrum such as short iterations, incremental building, customer involvement, adaptation to changing requirements, and constantly adjusting scope, time, and cost within the project will still apply.

Acceptance or Rejection of Prioritized Product Backlog Items

Toward the end of any iteration, the respective business unit and business stakeholders participate in a Sprint Review Meeting in which the product increment is demonstrated to the Product Owner, sponsor, customer, and users. While feedback from all the business stakeholders is gathered, only the Product Owner has the power to accept or reject that a particular User Story is Done according to the agreed upon Acceptance Criteria. Thus, the role of Acceptance Criteria in maintaining quality is critical and needs to be clearly understood by the team. It is the responsibility of the Scrum Master to ensure that the Acceptance Criteria for a User Story are not changed by the Product Owner in the middle of a Sprint. Partially completed User Stories are rejected as not Done and moved back into the Prioritized Product Backlog.

Acceptance Criteria

The second half of the User Story is the Acceptance criteria.  Defined by the Product Owner (the voice of the customer) during User Story decomposition, acceptance criteria sets the expected functionality that each intended task is to provide. It details the requirements that must be met for each story to be completed and answers the question, “How will the development team know when they are done with a story”.

Acceptance criteria may be clearly detailed or vaguely composed

· The pull down menu color in the payment screen must be PB15:1 (Windsor Blue RS)

· Meet ISO9001 – 8.5.2 Requirements for Analysis and Improvement

· Have a systematic approach to fix nonconformity and stop it from recurring, including a procedure.

Acceptance criteria can be ambiguous

· Fishing ads do not make it to the reply form or info request page

· Cart-payment page does not hang upon CC submission
Done

Tasks are part of User Stories that are either completed or not.  Completed tasks are tracked on the Sprint Burn-down Chart where the Scrum team deducts completed work from the Sprint.

Partially completed tasks do not satisfy acceptance criteria and should be moved back to the product backlog for further clarification or prioritization and taken up on the next sprint.

Expect to test

In meeting the requirements of the acceptance criteria (a result of a well-defined user story) as part of the development of a potentially ship-able product, the development team may implement tools to test different stages of product development and build a working software that creates specific observable results. This is  an effective way to continuously verify that the acceptance criteria is met.

Dos and Don’ts

· Focus on meeting each item's acceptance criteria and maintain technical excellence

· Stay focused on building the minimum code required to satisfy the acceptance criteria for the current sprint.

· Do not gold plate

· Feature creeps (resulting from a poorly understood user story) takes time away from developing expected value.

· Assisting the PO in refining the product backlog can be a effective use of time should the development team have remaining sprint time,

· Sprints should not be extended if the development team needs more time to complete a given user story

· Don’t give partial credit for items that don’t meet acceptance criteria.

Potentially Ship-able product

As stated earlier, Acceptance Criteria sets the parameters that the development team needs to meet for the sprint items (tasks) to be completed within the velocity of a sprint.  Doing so builds customer value, delivers working software more frequently and gets the team closer to building a potentially ship-able product that works as intended and meets the conditions of the Product Owner. 

The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project. The required features are described in the form of User Stories. User Stories are specific requirements outlined by relevant business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria, which are the objective components by which a User Story’s functionality is judged.

A clear definition of Done is critical because it helps clarify requirements and allows the team to adhere to quality norms. It also helps the team think from the user’s perspective when working on User Stories. Acceptance Criteria are developed by the Product Owner according to his or her understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members and their agreement is sought. Acceptance Criteria should explicitly outline the objective conditions that User Stories must satisfy for them to be accepted by the Product Owner.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject deliverables. If deliverables are accepted by the Product Owner, then the User Story is considered ‘Done’.

Although Acceptance Criteria are unique to each User Story, they are not a substitute for a requirements list. It is important for a Product Owner to note that User Stories that fulfill most, but not all, Acceptance Criteria cannot be accepted as Done. Scrum projects operate in Time-boxed Sprints, with a dedicated Sprint Backlog for each Sprint. Often, the last bit of work might be the most complicated part of a User Story and might take longer than expected. If incomplete User Stories were given partial credit for being Done and carried over to the next Sprint, then the progress of the subsequent Sprint could be disrupted. Therefore, the Done status is black and white. A User Story can only be either Done or not Done.

Let us now look at the key differences between “Done Criteria” and “Acceptance Criteria.” While Acceptance Criteria are unique for individual User Stories, Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. General Done Criteria could include any of the following:

• Reviewed by other team members
• Completed unit testing of the User Story
• Completion of quality assurance tests
• Completion of all documentation related to the User Story
• All issues are fixed
• Successful demonstration to business stakeholders and/or business representatives

As with the Acceptance Criteria, all conditions of the Done Criteria must be satisfied for the User Story to be considered Done.

The Scrum Team should use a checklist of the general Done Criteria to ensure a task is finished and the result meets the Definition of Done (DoD). A clear Definition of Done is critical because it helps remove ambiguity and allows the team to adhere to required quality norms. The required records and data to comply with the project’s documentation requirements can be generated as the team proceeds through Sprints and Releases.

The inclusion of activities such as holding review meetings and writing design documents can help ensure compliance with internal and external quality standards. The basic principles of Scrum such as short iterations, incremental building, customer involvement, adaptation to changing requirements, and constantly adjusting scope, time, and cost within the project will still apply.

Acceptance Criteria are the measurable standards used to assess the functionality of a User Story. They're developed by the Product Owner based on their understanding of the customer's needs. These criteria should detail the requirements that User Stories need to meet. At the end of each Sprint, the Product Owner uses these criteria to evaluate the completed work, deciding whether to approve or reject individual deliverables and their associated user stories. Well-crafted acceptance criteria should cover aspects like usability, performance, functionality, error handling, and stress testing.

Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project. It is a challenge for Scrum Product Owner to come up with and describe the boundaries of User Stories based on limited information.

Product Owner’s decision making is based on ways looking for safe solutions (principles of satisficing), the information and the time they have to make decisions. That is, their decision-making strategy attempts to meet an acceptability threshold rather than finding the best option available. They do not stick to make optimized decisions.

Scrum projects operate in Time-boxed Sprints and due to time constraints it is not always possible to provide a detailed list of criteria that will cover the User story as a whole. Therefore, Product Owner comes up with a list that is good enough to move the sprint ahead.

Product Owner begins conversations with the customer and stakeholders for outlining specific requirements as they pertain to the proposed product or service and begin the search for the optimal list of Acceptance Criteria. But in reality, the Product Owner identifies a list of criteria which is highly visible and not comprehensive or exhaustive. Once the list is identified, the product owner discusses them with the team. Review begins with alternatives, differing a little from the current choice of list, along with the team and it continues until the product owner identifies an alternative that meets acceptable level of performance.

Constituting an exhaustive list for Acceptance Criteria is not mandatory but they should be sufficient to move the sprint forward. Acceptance Criteria are limited by time and they do not add internal value to the future product.

Role of Acceptance Criteria in maintaining quality is critical and needs to be clearly understood by the team members. User Stories should be able to ignite ideas in team members so that presence of a detailed list of criteria covering all aspects is no longer being required.

Acceptance Criteria are the objective standards used to evaluate a User Story's functionality. The Product Owner, drawing from their expertise in understanding customer needs, develops these criteria. They should clearly define the conditions that User Stories need to meet. After each Sprint, the Product Owner employs these criteria to assess completed deliverables. They have the authority to approve or reject individual deliverables and their associated user stories based on these criteria. Good acceptance criteria cover Usability, Performance, Functionality, Error handling, and Stress tests.

Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project. It is a challenge for Scrum Product Owner to come up with and describe the boundaries of User Stories based on limited information.

Product Owner’s decision making is based on ways looking for safe solutions (principles of satisficing), the information and the time they have to make decisions. That is, their decision-making strategy attempts to meet an acceptability threshold rather than finding the best option available. They do not stick to make optimized decisions.

Scrum projects operate in Time-boxed Sprints and due to time constraints it is not always possible to provide a detailed list of criteria that will cover the User story as a whole. Therefore, Product Owner comes up with a list that is good enough to move the sprint ahead.

Product Owner begins conversations with the customer and stakeholders for outlining specific requirements as they pertain to the proposed product or service and begin the search for the optimal list of Acceptance Criteria. But in reality, the Product Owner identifies a list of criteria which is highly visible and not comprehensive or exhaustive. Once the list is identified, the product owner discusses them with the team. Review begins with alternatives, differing a little from the current choice of list, along with the team and it continues until the product owner identifies an alternative that meets acceptable level of performance.

Constituting an exhaustive list for Acceptance Criteria is not mandatory but they should be sufficient to move the sprint forward. Acceptance Criteria are limited by time and they do not add internal value to the future product.

Role of Acceptance Criteria in maintaining quality is critical and needs to be clearly understood by the team members. User Stories should be able to ignite ideas in team members so that presence of a detailed list of criteria covering all aspects is no longer being required.

The Prioritized Product Backlog is a document that outlines the project scope. It lists the features of the product or service to be delivered, ranked by importance. These features are detailed as User Stories.

User Stories are specific requirements outlined by various business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria (also referred to as “Acceptance Criteria”), which are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members and their agreement is sought.

Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy. Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject individual deliverables and their associated User Stories. If deliverables are accepted by the Product Owner, then the User Story is considered Done. A clear definition of Done is critical because it helps clarify requirements and allows the team to adhere to quality norms. It also helps the team think from the user’s perspective when working with User Stories.