Scrum Notes

Eray ALTILI

Mar 28, 2020·11 min read

An application of agile methodology to projects.

6 Principals of Scrum

1. Empirical Process Control — transparency, inspection, and adaptation.
2. Self-organization — This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more conducive for growth.
3. Collaboration It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value.
4. Value Based Prioritization — This principle highlights the focus of Scrum to deliver maximum business value, from beginning early in the project and continuing throughout.
5. Time-boxing — This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings.
6. Iterative Development — This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development.

Roles

• Product Owner : is the person responsible for achieving maximum business value for the project. He or she is also responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.
• Scrum Master: is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.
• Scrum Team: is the group or team of people who are responsible for understanding the requirements specified by the Product Owner and creating the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer.
• Executives: They are the sponsors of the projects who are accountable to the organization
• End User : They are the customers that requests features to solve problems

Quality Assurance and Change Management

To ensure a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement. Constantly keep the Prioritized Product Backlog updated with any changes in requirements. The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.

Since Scrum requires work to be completed in increments during Sprints, this means that errors or defects get noticed earlier through repetitive quality testing, rather than when the final product or service is near completion. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team-this ensures that quality is inherent in any deliverable created as part of a Sprint. Such deliverables from Scrum projects, which are potentially shippable, are referred to as ‘Done.’

Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Scrum Aspects

The 5 Scrum aspects must be addressed and managed throughout a Scrum project.

1. Organization — Understanding defined roles and responsibilities in a Scrum project.
2. Business Justification — This aspect focuses on the concept and purpose of Business Justification as it relates to Scrum projects. It is important for an organization to perform a proper business assessment prior to starting any project. This helps key decision makers understand the business need for a change or for a new product or service, the justification for moving forward with a project, and its viability.
3. Quality — Focuses on defining quality as it relates to projects and approach to achieve the required levels of quality. Quality defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer.
4. Change — Focuses on the importance of change in any project, regardless of its method or framework and expands on development processes are designed to embrace change.
5. Risk — Focuses on management of risks in a Scrum environment by considering various tools that facilitate the management of risks. Managing risk must be done proactively, and it is an iterative process that should begin at project initiation and continue throughout the project’s lifecycle. The process of managing risks should follow some standardized steps to ensure that risks are identified, evaluated, and a proper course of action is determined and acted upon accordingly.

Scrum Phases

Scrum processes address the specific activities and flow of a Scrum project. In total there are 19 processes which are grouped into following five phases:

1. Initiate — This phase includes the processes related to initiation of a project: Create Project Vision, Identify Scrum Master and Stakeholder(s), Form Scrum Team, Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning.
2. Plan and Estimate -This phase consists of processes related to planning and estimating tasks, which include Create User Stories, Approve, Estimate, and Commit User Stories, Create Tasks, Estimate Tasks, and Create Sprint Backlog.
3. Implement — This phase is related to the execution of the tasks and activities to create a project’s product. These activities include creating the various deliverables, conducting Daily Standup Meetings, and grooming (i.e., reviewing, fine-tuning, and regularly updating) the Product Backlog at regular intervals.
4. Review and Retrospect — This phase is concerned with reviewing the deliverables and the work that has been done and determining ways to improve the practices and methods used to do project work.
5. Release — This phase emphasizes on delivering the Accepted Deliverables to the customer and identifying, documenting, and internalizing the lessons learned during the project.

These phases describe each process in detail including the associated inputs, tools, and outputs of each. Following is the complete list of 19 Scrum processes.

Initiate Phase

The Initiate phase consists of following six processes:

1. Create Project Vision — In this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process.
2. Identify Scrum Master and Stakeholder(s) — In this process, the Scrum Master and Stakeholders are identified using specific Selection Criteria.
3. Form Scrum Team — In this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master.
4. Develop Epic(s) — In this process, the Project Vision Statement serves as the basis for developing Epics. User Group Meetings may be held to discuss appropriate Epics. Epic is a big chunk of work which can be divided into smaller user stories. An Epic can be spread across sprints and even across agile teams. An Epic can be a high-level description of what the client wants, and accordingly, it has some value attached to it. User stories are requested features by customer to do something valuable in their role. As a (role) I want to … so that … (Role, request, value and justification)
5. Create Prioritized Product Backlog — In this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria is also established at this point.
6. Conduct Release Planning — In this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process.

Plan and Estimate Phase

The Plan and Estimate phase consists of following five processes:

1. Create User Stories — In this process, User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. User Story Writing Exercises may be held which involves Scrum Team members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog. User stories are requested features by customer to do something valuable in their role. As a (role) I want to … so that … (Role, request, value and justification)
2. Approve, Estimate, and Commit User Stories — In this process, the Product Owner approves User Stories for a Sprint. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story, and the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories.
3. Create Tasks — In this process, the Approved, Estimated, and Committed User Stories are broken down into specific tasks and compiled into a Task List. Often a Task Planning Meeting is held for this purpose.
4. Estimate Tasks — In this process, the Scrum Core Team, in Task Estimation Meetings, estimate the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List.
5. Create Sprint Backlog -In this process, the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint. Scrum Burndown Chart and Kanban Board created.

Sprint is one timeboxed iteration of a continuous development cycle that is maximum one month. Within a Sprint, planned amount of work has to be completed by the team and made ready for review.

The Scrum and Sprint Burndown Chart created that is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release. Its purpose is to enable that the project is on the track to deliver the expected solution within the desired schedule.

Team Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories. The main purpose of the velocity chart is to overview how much work has been delivered for each sprint. It will help you to have a clear view on future perspectives and on the workload of your team.

Scrum/Kanban boards visually depict work at various stages of a process using cards to represent work items and columns to represent each stage of the process. (backlog, stories, Sprints, tasks (to do), development, testing, deployment, done)

Implementation Phase

Implementation phase consist of following three processes:

1. Create Deliverables — In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. A Scrumboard is often used to track the work and activities being carried out. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log.
2. Conduct Daily Standup — In this process, everyday a highly focused, Time-boxed meeting is conducted referred to as the Daily Standup Meeting. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing.
3. Groom Prioritized Product Backlog — In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate.

Review and Retrospect phase

The Review and Retrospect phase consist of following three processes:

1. Convene Scrum of Scrums — In this process, Scrum Team representatives convene for Scrum of Scrums (SoS) Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams. This is relevant only for large projects where multiple Scrum Teams are involved.
2. Sprint Review — In this process, Demonstrate and Validate Sprint. Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance from the Product Owner for the Deliverables created in the Sprint.
3. Retrospect Sprint -In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints.

Release Phase

Release phase consists of following two processes:

1. Ship Deliverables — In this process, Accepted Deliverables are delivered or transitioned to the relevant stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.
2. Retrospect Project — In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.

Scaling Scrum for Large Projects

Large project team that coordinates activities of multiple Scrum Teams in one big project to produce potentially shippable product increments/deliverables. * are mandatory

Create Large Project Components

This process defines how the multiple Product Owners work together and how the multiple Scrum Teams work together. Also, common components and common and specialized resources are identified.

Conduct and Coordinate Sprints

Scrum of Scrums Meetings are conducted to coordinate efforts between multiple Scrum Teams.

Prepare Large Project Release

In large projects it makes business sense to do a special Sprint prior to a release

Scaling Scrum for Enterprise

Scaling Scrum for the Enterprise applies Portfolios, programs, and/or projects.

Create Program or Portfolio Components

Program or Portfolio Product Owner and key stakeholders identify common components and resources required for the program or portfolio. The Minimum Done Criteria are defined and all stakeholders are identified.

Review and Update Scrum Guidance Body

Scrum Guidance Body Recommendations are regularly reviewed by the members of the Scrum Guidance Body and are updated when and if necessary. Changes in the membership of the Scrum Guidance Body are also handled.

Create and Groom Program or Portfolio Backlog

Program or Portfolio Backlog is created, updated, and maintained. Suggested improvements for the Scrum Guidance Body Recommendations may be made and implementation deadlines may be adjusted based on changed requirements and/or progress of the projects in the program or portfolio. Following figure shows the relationship of the Create and Groom Program or Portfolio Backlog process to the fundamental Scrum processes.

Coordinate Program or Portfolio Components

Components of the program or portfolio are coordinated. Dependencies between projects are addressed, common impediments are discussed, and best practices are shared.

Retrospect Program or Portfolio Releases

Program or Portfolio Product Owner and key stakeholders get together to retrospect a program or portfolio Release and internalize the lessons learned to agreed actionable improvements to be implemented in future releases.

Originally published at https://github.com/ealtili/Blog/blob/master/ScrumNotes.md