Scrum - Chapter 5

Done Criteria

*Set of rules applicable to all user stories. *It removes ambiguity from requirements. *Helps the team adhere to quality norms.

Quality and Scope Requirements

1. The business need the project will fulfill 2. The capability and willingness of the organization to meet the identified business need 3. The current and future needs of the target audience

Minimum Done Criteria

A higher level business unit may announce mandatory minimum Done Criteria - this becomes part of the Done Criteria for any User Story for that Business Unit.

Plan-Do-Check-Act (PDCA) Cycle

A performance improvement model developed by Walter Shewhart, but popularized in Japan by W. Edwards Deming Deming modified Plan-Do-Check-Act to Plan-Do-Study-Act because he felt the term 'Study' emphasized analysis rather than simply inspections as implied by check. Both Scrum and PDCA are iterative methods that focus on continuous improvement.

Prioritized Product Backlog

A single requirements document that defines the project scope buy providing a prioritized list of features of the product or service to be delivered by the project.

Key Difference - Done Criteria and Acceptance Criteria

Acceptance Criteria are unique for individual stories Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint

Quality Management (Scrum)

Customer is the most important stakeholder for any project. Customer may be internal / external QM is facilitated through three interrelated activities: 1. Quality planning 2. Quality Control 3. Quality assurance

Quality Planning - key benefit

Key benefit is the reduction of technical debt

Stages of PDCA

Plan *Create Prioritized Product Backlog *Create User Stories Do *Create Deliverables *Conduct daily Standup Check/Study *Demonstrate and Validate Sprint *Retrospect Sprint Act *Ship Deliverables *Retrospect Project

Quality Control and Quality Assurance

QC - refers to the execution of the planned quality activities by the Scrum Team in the process of creating deliverables that are potentially shippable. QA - refers to the evaluation of processes and standards that govern quality management in a project to ensure that they continue to be relevant.

User Stories

Required features from the project scope are described in the form of User Stories. They are specific to requirements outlined by various 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. If deliverables are accepted by the Product Owner then the User Story is considered done. User Stories can either be Done or Not Done

Quality and Scope (Scrum)

Scope of the project is the total sum of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy the customer needs. Both are captured in the Prioritized Product Backlog and the scope for each Sprint is determined by refining the large Prioritization Product Backlog Items into a set of small but detailed User Stories that can be planned, developed and verified within a Sprint. The Prioritized Product Backlog is continuously groomed by the Product Owner. They ensure that any User Stories that the Scrum Team is expected to do in a Sprint are refined prior to the start of the Sprint.

Technical Debt

also referred to as design debt / code debt refers to the work that teams prioritize lower, omit, or do not complete as they work toward creating the primary deliverables associated with the project's product. Technical debt accrues and must be paid in the future. Causes: *Quick fix and building deliverables that do not comply with standards for quality, security, long-term architecture goals etc. *Inadequate or incomplete testing *Improper or incomplete documentation *Lack of coordination among different team members *Poor sharing of business knowledge and process knowledge among the stakeholders and project teams *Too much focus on short-term project goals instead of the long-term objectives of the company TD is not carried over beyond a Sprint because there should be clearly defined Acceptance and Done Criteria. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.

Acceptance Criteria

developed by the Product Owner according to his / her expert understanding of the customer's requirements

Quality (Scrum)

the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer.