In Part 1 we extensively covered the basics about Scrum, Agile Manifesto , the Principles, facts and myths about Scrum and the roles within the team.
In this post we will concentrate on understanding and will do a deep dive analysis of:
- Scrum Events
- Scrum Activity – Backlog Grooming
- Scrum Activity – Slack
Scrum Events
Scrum events are designed to enable critical transparency, inspection, regularity, and adaptation. You must prefer to use these predefined meetings with fixed objectives and maximum durations instead of ad-hoc meetings, which most likely waste our time.
There are just five events in a Scrum Project:
1. Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four other events (as represented in the above diagram), development effort, and the maintenance of the Product Backlog.
2. Sprint Planning: Sprint Planning is the first event inside a Sprint. The Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them.
3. Daily Scrum: The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed. 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.
4. 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).
5. 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.
Timebox Concept
Time Box is an essential concept in Agile methods, a predefined fixed maximum duration of time in order to maximize productivity 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. 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 on”.
1. Sprint
Each Scrum project delivers the final product after a number of cycles, which are called Sprints. An Increment is developed in each Sprint. An Increment is a potentially releasable part of the final product. An Increment is a sum of all Product Backlog items completed so far in a project and this Increment keeps getting bigger after each Sprint. Therefore you can consider each new Increment at the end of a Sprint to be an 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, which means we should fix its duration at the beginning of the project and do not change it frequently or occasionally. Sprints are usually fixed for one month or less.
An important point is that we do not change the items of the Sprint Backlog after the Sprint is started and the plans are set. The Sprint Goal (discussed further in Sprint Planning) should not change either. The Product Owner and the Development Team might try to clarify and re-negotiate the scope as more is learned as more is leaned about the items to be delivered, but will not change the Sprint Backlog. Even the composition of the Development Team should not change during a Sprint. These constraints are designed to make it possible to focus and get things done.
Each item (story) in the Product Backlog should normally be developed (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 (this has already been prioritized by the Product Owner) and aim to get them “Done” (100% complete). We want them to be really “Done” when the Sprint is over, and create an Increment. An Increment is the sum of all the completed items during a Sprint and all previous Sprints.
It is important to agree on a definition of “Done” at the beginning of the project. We will not call something “Done”, unless it fits the definition. A 99.999% completed item is not considered as “Done”, it would not be part of the Increment and it would not be demonstrated to the customer at the Sprint Review.
Sprint Time boxes: Most companies use Sprint time boxes of 2 to 4 weeks. If we use time- boxes longer than one calendar month for Sprints, it will be likely for the unapplied changes to become large enough to create problems. This will increase the complexity and risk.
Therefore, we should keep the Sprints no more than one calendar month. Sprints should not be too short either, because we would not be able to produce complete Backlog items during it. Our 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.
Can a Sprint be cancelled? Even though each Sprint is frozen and does not change, the Product Owner has the authority to cancel a Sprint. This can happen when the Sprit Goal becomes obsolete, due to changes in the Product Backlog, strategies, approach, etc. 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 Planning
The Development Team does not wait until the Product Backlog is 100% planned (all requirements are gathered and cleared) to start developing the project. As soon as the Product Backlog is mature enough (has the necessary number of stories) which will provide the information for the Sprint, the Product Owner and the Development Team can start the first Sprint.
The first thing to do in each Sprint is Sprint Planning. Sprint Planning is a time-boxed meeting, usually fixed to 8 hours for a one month Sprint, or shorter for Sprints of less than a month. All three roles should attend this meeting.
The Development Team should estimate the capacity of work it can deliver in a single Sprint. The Product Owner has already ranked and ordered the Product Backlog based on the value of the items. The Product Owner also ensures that the items (stories) are easy to understand. The Development Team then 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 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.
Following the selection of the items, the Scrum Team should draft a Sprint Goal. The Sprint Goal is 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.
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. These details should be aligned with the Sprint Goal, and likely re-negotiations for them should be done in presence of the Product Owner. The Sprint Goal is also included in the Sprint Backlog.
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. This is the last part of the Sprint Backlog. The Sprint planning is not necessarily completed in this meeting; having a detailed plan for the first few days is enough; 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.
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.
There is no specific rule on documenting, storing, and presenting the Sprint Backlog. It can be written on a board (wall chart) similar to one shown in the following figure.
Yellow sticky notes (post-its) on the above board are tasks that are created by breaking down each of the items. These tasks define what the Development Team will do to deliver each item, and they are responsible for preparing them. Some tasks are created at the Sprint Planning meeting, and some others throughout the Sprint.
The Sprint Backlog consists of the following:
1. The Sprint Goal
2. Selected items from the Product Backlog, to be delivered through the Sprint
3. A detailed plan for turning the selected items (stories) into “Done” Increment of the product and to realize the Sprint Goal
As you can see, the three Sprint Backlog elements (Sprint Goal, Product Backlog items selected for the Sprint, and the detailed plan) are shown on the sample board. This sample Scrum board has also extra features for tracking the tasks and items in “To Do”, “Doing”, and “Done” columns. The next figure shows the same Sprint after the first item is complete and items #2 and #3 are in progress.
You can also see that 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.
3. Daily Scrum
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.
During the Daily Scrum, each member of the Development Team should answer these three questions:
1. What has been accomplished since the last meeting?
2. What will be done before the next meeting?
3. What obstacles are in the way?
They should assess progress towards the Sprint Goal and forecast the likelihood of completing the items before the Sprint is over.
The Daily Scrum meeting should be held at the same time and place throughout the Sprint, to minimize the complexity. It is just for the Development Team; it is not a status meeting for all the stakeholders.
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.
The above figure contains the Sprint Burn-Down Chart (the tracking information) and this can be updated after each Daily Scrum meeting. Burn-Down Charts are discussed further in the next section.
4. Sprint 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.
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 and adapt 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 Development Team does not present an item, unless it is 100% complete based on the agreed definition of “Done”. The Product Owner makes sure (before the Scrum Review) that presented items are “Done”. The Development Team demonstrates and explains the items.
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.
5. Sprint Retrospective
This meeting is normally three hours for a one month Sprint. If the Sprint is shorter than one month, this meeting will be proportionally shorter.
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.
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. We will review (inspect) the Sprint, with regards to people, relationships, processes, and tools, and identify ways of improving them in the next Sprint.
Scrum Activity – Backlog Grooming
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.
Scrum Activity – Slack
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.
Note that the slack is not an event or activity in the official Scrum Org and it does not mention it.