Scrum events

Discover events nature, Time-Box, Sprint, Backlog Grooming, Slack

There are just five events in a Scrum Project:

Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four other events, development effort, and the maintenance of the Product Backlog.
Sprint Planning: first event inside a Sprint where the Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them.
Daily Scrum: During the Sprint, the Development Team holds a daily meeting (normally 15 minutes) to coordinate the work for the next 24 hours. This meeting is called the Daily Scrum.
Sprint Review: Before the end of the Sprint, the Development Team presents (demonstrates) the outcome of the Sprint to the customer and receives feedback. This meeting is called Sprint Review (also known as Sprint Demo).
Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint. This meeting is called Sprint Retrospective.

Events description

The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed.
The events are designed to enable critical transparency, inspection, regularity and adaptation. We prefer to use these predefined meetings with fixed objectives and maximum durations instead of ad-hoc meetings, which most likely waste our time.
There is an essential concept in Agile methods, called time-box: a predefined fixed maximum duration of time. In order to maximize productivity, all of the Scrum events must be time-boxed.

Get the book

Time-Box Concept

Discover fixed period of time, freeze the target, full focus

Time-Box description:

Time-box is an essential concept in Scrum.
A time-box is a fixed period of time in which we freeze the target and work with full focus on certain tasks or objectives.
Time-boxed events repeat many times, until the final goal of the project is achieved.
All the changes are applied only when one time-box is finished and we are ready to start the next one.
The duration of a time-box should be agreed upon and fixed.

NOTE: We are free to change the duration based on lessons learned, but not frequently, and never based on single occasions. For example, we are not allowed to say that we have a lot to do this time, so let’s increase the duration for this particular case. What we are allowed to say is based on the previous ten time-boxes, we realized that the duration of our time-boxes is not suitable, and a 30% increase in duration might better fit our needs. So, let’s increase them from now.
Time-Box benefits:

Time-Box is our way of staying focused and getting things done in an ever-changing environment.

Get the book

Sprint

Discover Increment, sum of all completed PBI, updated version, request changes, sprint goal, cancel a Sprint

Sprint description:

Each Scrum project delivers the final product after a number of cycles, which are called Sprints.
An Increment is the sum of all Product Backlog items completed so far in a project and this Increment keeps getting bigger after each Sprint.
An Increment is developed in each Sprint, which is a potentially releasable part of the final product.
An Increment is the updated version of the previous Increment with new features and functionalities, which may or may not be actually released (put into use), but should always be potentially releasable.
Customers usually request changes when they see the Increment (during the Sprint Review), and we note these new requests in the Product Backlog.
Sprint is a time-boxed event, with a fix duration (set at the beginning of the project and do not change it frequently or occasionally). Sprints are usually fixed for one month or less (usually 2 to 4 weeks) as any longer would increase risk and complexity,
The sprint goal is to deliver the final product item by item, inside the Sprints; we do not want to split a single Product Backlog item among several Sprints.
The Product Owner has the authority to cancel a Sprint, usually when the Sprit Goal becomes obsolete, due to changes in the Product Backlog, strategies or approaches. When a Sprint is cancelled, the items that are Done will be reviewed and accepted, and the rest of the items (not started or partly complete) will be put back into the Product Backlog to be done in the future.

Sprint rules:
Scrum have a set of constraints designed to make it possible to focus and get things done including:

The Sprint Backlog items should not be changed once the Sprint is started
The Sprint Goal should not be changed.
The composition of the Development Team should not change during a Sprint.
The Product Owner and the Development Team might try to clarify and re-negotiate the scope as more is learned about the items to be delivered, but will not change the Sprint Backlog.
Each item (story) in the Product Backlog should normally be completed in a single Sprint as this is much easier to manage.
The Product Owner and the Development Team select a number of items from the top of the Product Backlog, that have already been prioritized by the Product Owner, and aim to get them Done (100% complete).
The Sprint Backlog items should be completed matching the definition of Done when the Sprint is over, and create an Increment.
A definition of Done should be agreed at the beginning of the project, and no item should be identified as Done, unless it fits the definition (even if 99.999% completed) as it would not be part of the Increment and it would not be demonstrated to the customer at the Sprint Review.

Get the book

Sprint Planning

Discover time-boxed meeting, estimate the capacity, Sprint Backlog, Sprint Goal, Sprint PBI and detailed plan

Sprint Planning overview:

The first thing to do in each Sprint is the Sprint Planning, which is a time-boxed meeting attended by all 3 scrum roles and usually fixed to 8 hours for a one month Sprint or shorter for Sprints of less than a month.
The Development Team should estimate the capacity of work it can deliver in a single Sprint from the already ranked and ordered Product Backlog with the highest value items on top.
As soon as the Product Backlog is mature enough, with necessary number of stories the Development Team can start the first Sprint without waiting until the Product Backlog is 100% planned with all requirements gathered and cleared.
The Sprint Backlog will be ready at the end of this meeting and the Development Team should be able to describe what items they will deliver through the Sprint, and how they will do it.

Product Backlog to Sprint Backlog

The Development Team selects an appropriate number of items from the top of the Product Backlog, and puts them in the Sprint Backlog, to deliver in the current Sprint.
The Product Owner also ensures that the items (stories) are easy to understand.
The amount of work for each item is estimated by the Development Team and the total amount of work of the selected Product Backlog items is close to the estimated capacity of the Development Team.

Sprint Goal:

Following the selection of the items to the Sprint Backlog, the Scrum Team should draft a Sprint Goal, an objective that should be met within the Sprint through the implementation of the Product Backlog.
The Scrum Goal provides guidance to the Development Team on why it is building the Increment.
This is a sample Sprint Goal: We are going to enable all the essential parts of the website store to set up a complete purchase process. This makes other features of the website more meaningful to the customer.
The Product Backlog should be ordered in a way that facilitates setting Sprint Goals.
The scope of the Sprint, which is made up of the items selected from the Product Backlog, might need to have more details through the Sprint, which should be aligned with the Sprint Goal, and likely re-negotiations for them should be done in presence of the Product Owner.

Detailed plan:

When the items to deliver are selected and the Sprint Goal is agreed, it is time to plan how they will deliver the items into a Done product Increment and realize the Sprint Goal.
Having a detailed plan for the first few days is enough and the Development Team can prepare detailed plans for the rest of the work later on.
A detail plan, as shown in the next figure, is a breakdown of a Product Backlog item into detailed tasks needed to be done in order to create the item.
Each task might have estimates, dependencies, and similar information to make tracking possible.
These tasks are defined by the Development, explaining how they will deliver each item, and are created at the Sprint Planning meeting or throughout the Sprint.

The Sprint Backlog consists of the following:

The Sprint Goal
Selected items from the Product Backlog, to be delivered through the Sprint
A detailed plan (tasks) for turning the selected items (stories) into Done Increment of the product and to realize the Sprint Goal

Sprint board:

The three Sprint Backlog elements (Sprint Goal, Product Backlog items selected for the Sprint, and the detailed plan) should be shown on the board.
The board should also have an easy way for tracking the tasks and items in To Do, Doing and Done columns.
Extra tasks have been added to the lower ranked items (items #3 to #5), which is the ongoing detail planning done through the Sprint.
Items in the Sprint Backlog usually have the same order they had in the Product Backlog, therefore, the Development Team should work on the higher ordered items first.

Get the book

Daily Scrum

Discover 15 minute daily, same place/same time, sprint progress (board, burnt down chart), scrum team only, 3 questions (done, to do, obstacles)

Daily Scrum overview

The Daily Scrum is normally a 15 minute meeting for the Development Team to inspect the work since the last meeting, and synchronize their work and plan for the next 24 hours.
It must be held on a daily basis, ideally at the same time and place.
The Daily Scrum meeting should be held at the same time and same place throughout the Sprint, to minimize the complexity.
It is just for the Development Team and it is not a status meeting for all the stakeholders.
They should assess progress towards the Sprint Goal and forecast the likelihood of completing the items before the Sprint is over.

During the Daily Scrum, each member of the Development Team should answer these three questions:

What has been accomplished since the last meeting
What will be done before the next meeting
What obstacles are in the way

Sprint progress:

The Development Team should also monitor Sprint progress each day and therefore it is a good idea for the Sprint board (wall chart) to be visible during the Daily Scrum meeting.
They can use a burn-down chart to track their remaining work and check to see if they are going to complete all items before the end of the Sprint.

Get the book

Sprint Review

Discover 4 hours, inspect the Done items, demo, meet DOD, update PB, get feedback/changes, status

Sprint Review overview:

At the end of the Sprint, the Scrum Team and other stakeholders gather and hold a four hour meeting to present and inspect the Done items (the Increment) from the current Sprint.
The Development Team demonstrates and explains each one of the items.
The Development Team does not present an item, unless it is 100% complete based on the agreed definition of Done, which should be reviewed by the Product Owner before the Scrum Review.
The duration of this meeting is normally four hours for a one month Sprint. If the Sprints are shorter then this meeting will be proportionally shorter.

Sprint Review objectives:

Update the Product Backlog by marking off Done items as complete and add new items or change the existing ones if necessary.
The presentation of the Increment in this meeting is intended to collect feedback and raise change requests at the earliest time possible.
We welcome changes in Scrum and encourage them to be demanded, because it increases the satisfaction of the customer and will create a final product that better matches the needs of the customer.
The Product Owner discusses the status of the Product Backlog and the likely completion dates based on the progress.
Finally, the whole Scrum Team collaborates on revising the Product Backlog based on the output of the Sprint and the feedback received from the customer.

Get the book

Sprint Retrospective

Discover three hours, lesson learn, process improvement, inspect (people, relationships, processes, and tools)

Sprint Retrospective overview:

This meeting is normally three hours for a one month Sprint or shorter for proportionally shorter sprint.
After the Sprint Review and just before the end of the Sprint, another meeting will be held, aimed at process improvement (learning lessons), which is called Sprint Retrospective.
We will review (inspect) the Sprint, with regards to people, relationships, processes, and tools, and identify ways of improving them in the next Sprint.

Sprint Retrospective objectives:

There is a rule: we should always look for ways to improve. It does not matter how little the improvement is, there should be an improvement.
This meeting is a formal opportunity for improvement, even though we do not limit our improvement to the results of this meeting.

Get the book

Product Backlog Grooming

Discover reviewing and revising PBI, ordering, prioritizing, ongoing activity, max 10% of dev team

Product Backlog Grooming overview:

Besides the time boxed event discussed before, there is also an ongoing activity in Scrum projects called Product Backlog grooming. It is the act of reviewing and revising Product Backlog items, which typically involves adding detail, estimates, and order to them.
The Product Owner is responsible for ordering (prioritizing) the items and the Development Team is responsible for estimating those items.
The main difference between this activity and the five Scrum events is that Scrum events are all time-boxed, but grooming is an ongoing activity that happens throughout the Sprint.
This activity should not consume more than 10% of the time of the Development Team.

Get the book

Slack

Discover product-oriente, being productive, limit the work time to a reasonable amount, 1-2 days recharge batteries

It does not matter how much we work; what we produce is important.
We should be product-oriented, rather than activity-oriented.
One way of being productive, is to limit the work time to a reasonable amount, and have frequent off times.
That is why it is recommended (but not necessary) to have a slack between each two Sprints.
Let’s have a day or two off to recharge your batteries, read some relevant articles, and check out what other teams are doing.
Slacks can also be used for reading articles, taking part in courses or workshops, spending time on creative projects, etc.
We will be back after the slack, and repeat the same cycle over and over again, each time with a little improvement, until the final product of the project is delivered, and the client is completely satisfied with it.

Get the book