Chapter 3 Scrum Method

  1. Scrum methodology

1, Product backlog

  1. Sprint backlog
  1. Sprint week

4, Sprint review meeting, release

The implementation process of Scrum’s methodology can easily be explained with the help of the Scrum Famework. The framework is divided into three parts:

Roles

Ceremonies

Artifacts

PO, SM, DEVs

Sprint planning

The sprint planning meeting consists of the team, the Scrum Master, and the product owner. In the meeting, the product backlog items are discussed so that they can be prioritized and then the team selects which ones to do. The sprint planning meeting determines what will be worked on and it also helps to develop a considerable understanding of what needs to do in order to carry it out.

One notable thing done in sprint planning is that tasks are measured in time (whereas before it was done in story points).

A rule of thumb, a sprint planning takes approximately the number of weeks in sprint * 2 hours (4 hours in our case).

Daily scrum

The daily Scrum meeting is held daily for about 15 minutes. This is not a problem-solving meeting. The daily Scrum helps avoid unnecessary meetings. In the daily Scrum everyone answers three questions, which are:

· What did you do yesterday?

· What will you do today?

· Is anything in your way?

The sprint review

In the Sprint Review (can also be referred to a Review & Demo) the team presents what has been accomplished during the sprint. It is a demonstration of new features or the existing architecture. It is an informal presentation and the entire team participates in it.

Sprint retrospective

It involves looking at what is working and what is not. The time period for the sprint retrospective is around thirty minutes and is done after every sprint. It involves the participation of the product owner, Scrum master, team and even customers. In the retrospective, the whole team gathers to discuss what they want to start, continue, or stop doing.

The artifacts can be called the tools of the Scrum methodology and include the following:

Product backlog

The product backlog captures the requirements listed as items or works on the project. Each item is expressed in a way which provides value to the customer, prioritized by the product owner and reprioritized at the start of each sprint.

Sprint backlog

The sprint goal is a short statement about the focus of the work during the sprint. In the sprint, backlog work is never assigned and individuals choose their own work; the remaining work is estimated daily, and any member can add, changes, or deletes the sprint backlog. Sprint backlog determines the work for the sprint, is updated every day and each item has its own status.

Sprint burndown chart

The Sprint burndown chart shows the total sprint Backlog hours remaining each day and also the estimated amount of time to release. The sprint burndown chart should ideally come down to zero at the end of the sprint. The X-axis of the chart shows the time left in this sprint and the Y-axis show the hour’s estimated remaining.

  1. Benefits of scrum

Scrum methodology eliminates the need for comprehensive documentation

Mistakes can be easily rectified

Clear visibility of the project development

Iterative in nature and requires customer feedback

Short sprints and constant feedback make coping with changes easier

Individual productivity improves as a result of daily meetings

Issues are identified in advance and hence can be resolved rapidly

A quality product can be easily delivered in the scheduled time

Minimal overhead cost in terms of process and management

It helps with the delivery of top-value features first

Shorter time to market, which increases market feedback and ROI

System is better prepared for adaption to business and external changes

  1. Pitfalls

Tasks can be spread over several sprints if it is not well defined

Success and failure of the projects depends on the commitment of the team members

Heavily relies on a dedicated Product Owner. The lack of it cascades down and hinders the quality of the backlog, which has an impact on essentially the entire process

Works well only with a small team

Needs relatively experienced members

Works well for project management only when the Scrum Master trust the team

  1. Implementation example

A fixed time meeting is held at a fixed place each day

The Team Lead (Scrum Master) asks the team members about what they did the previous day, what they plan to do and if any issues were observed by them

Every day the team lead sends the report showing the daily progress and issues called a burndown chart

A meeting is held at the beginning of the sprint by the team lead to discuss the product backlog in order to prioritize the work, resource allocation and the issues known as the sprint backlog; they meet once every week for 2 to 4 weeks

The Product Owner defines the scope of the sprint based on the time estimates set at the sprint planning and the team’s capacity for the next sprint. This scope needs to be clearly communicated to the team since completing these tickets will be a commitment for the sprint

A daily Scrum meeting is held in order to synchronize the activities while the teams work through the spring backlog tasks

One more time during the sprint, backlog grooming sessions are held to present and discuss upcoming user stories for next sprints. The output may be an estimation of a story in story points, or if the team needs more clarifications, questions that the product owner needs to research on a sprint review is conducted at the end of the sprint cycle and the finalized product is released

Performances and improvements based on previous sprint cycle is discussed before starting with a new sprint; this is called sprint retrospective

The sprint cycle continues