Essentials of Scrum Practice

Home

WHAT IS SCRUM?

Overview of Scrum

Scrum is an iterative and incremental development approach; which means that in each iteration (cycle) an increment of functionality is created. A Scrum project is executed in a series of iterations, called Sprints. Each sprint starts with a Sprint Planning Meeting (SPM) where, what is to be developed and how to do so (i.e a goal and a plan) for the sprint is determined. The planning horizon for an SPM is the current sprint. After the SPM the team starts working on the sprint goal. They meet daily during the course of a sprint, for a short while in a meeting called the Stand-Up (or Daily Scrum) to synchronize and co-ordinate for adjustments towards the sprint goal. This continues as work gets done. At the end of the sprint the team demonstrates what has been developed (working software) to various stakeholders during the Sprint Review Meeting (SRM). The audience provides feedback and there is a quick evaluation as work items are accepted/rejected. A Retrospective is then conducted, where the team attempts to learn from it’s sprint experience and improve in the following sprints.

There are multiple sprints per release of a software product. The central approach of Scrum is the principle of “inspect and adapt”. There are many points in the course of a release and indeed within each sprint(see figure below) to do this. This is the basis of of scrum practice and conscientious, continuous and deliberate application of this approach is the manifestation of a deep understanding of Scrum.

Overview

In further sections, we look at specifics of the practices of Scrum including the roles that people play as defined in Scrum, activities in Scrum and artifacts associated with Scrum.

Sprints

Each Scrum iteration is called a Sprint, with a duration typically between two and four weeks. Lot of Scrum literature formally says four weeks, however two week sprints are quite common in practice and work quite well. A small minority of Scrum teams/projects use a sprint length of one week.

The end date of a sprint is never extended irrespective of whether work is finished or not. Similarly the scope of work, i.e the goals of the Sprint also does not change during the Sprint. Further the team that starts a Sprint should together as team at least for the course of the Sprint. These restrictions together constitute the “NO CHANGE RULE”. This rule provides an island of stability for a team to focus on a fixed target, in a fixed amount of time (sprint length).

The reason behind this is that the team has to learn how much work they can take on and complete successfully. If work is not completed in one Sprint, the incomplete portion of work is carried over to the next Sprint. First, the team will have to introspect and examine what went wrong and why what was thought to be feasible task list could not be completed. Once the team knows the reasons for inability to complete the tasks, it has to adapt and take corrective action for the next Sprint.

Scrum Roles

There are three roles defined in Scrum; they are the Product Owner, the Team and the ScrumMaster.

Product Owner

The Product Owner is responsible for communicating the vision of the product to the team. Product Owner is responsible for the success of the product to the extent that the product adheres to the requirements and ultimately to the vision of the product as envisaged by the stakeholders (in this context they may be Product Management team, external customers or internal customers who are end users or who represent the interests of the end users of the product).

It is Product Owner’s responsibility to discuss either with the customers or other external teams like Product Management etc and decide upon the features that need to be included in the product. Sometimes, Product Owner himself/herself can be the internal customer. It is also the Product Owner’s responsibility to prioritize these features such that their prioritization leads to extraction of maximum business value. Product Owner maintains a comprehensive list of all the features that are needed to be developed for the product and prioritizes them. This list is called Product Backlog.

Product Owner chooses what are the product features that get done in a Sprint in discussion with the Team and ScrumMaster. Product Owner should be constantly in touch with the customers, internal and/or external, and keep refining the list of features, elaborating them, pruning them, refining them and reprioritizing them. In a sense, the success or failure of the product, once it is successfully delivered by the team is responsibility of the Product Owner. Product Owner should work closely with the team and communicate with the team what are the tasks that need to be achieved and their priorities clearly. Product Owner should be available to the team to discuss and clarify any doubts that the team may have about the features that are being developed. As far as value of the work and the priorities of the tasks that gets done by the team in a Sprint is concerned, Product Owner is the final authority, so is it his responsibility.

It is also important to note that all of the features to be delivered for the product are communicated through the Product Owner by means of prioritized feature list and team is responsible for delivering the features to the Product Owner alone. This way, there is a single point of contact for the team as far as feature selection and prioritization is concerned and conflicts arising due to differing interests of multiple parties are avoided as the work is routed through Product Owner.

Team

The "Team" in Scrum is responsible for the “how” of any given sprint, responsible for building software functionality as directed by the product-backlog. They are the players in the Scrum game. The team has to construct software features sprint by sprint, and at the end of each sprint, these features must also be of acceptable quality (determined by the “definition of done”). In other words the team must take product backlog items from description to implementation. This means that the team must have all the skills to do so, therefore between the team members all skills required to convert the description of a given product backlog item to implementation should be present. Hence it would be a cross-functional team. [Harvard Business School Press]

The team also should understand that it is committed to the Sprint goal selected (by itself) during the Sprint Planning Meeting. Team members all work together to achieve this goal. They are not assigned tasks by a supervisor or manager. The team as a whole is responsible to deliver on commitments given to the Product Owner, not individual members for isolated tasks. In many knowledge work situations, a number of people working together are not only providing scale, they are often complementary. Team members all need to be aligned and committed to working in tandem to achieve the goal.

The other characteristic of Scrum teams is that they are self-organising as well as self-managing. The underlying thought here is that the more the team is autonomous and is able to take decisions (regarding the “how”), better the results.

The ideal size of a team about 7 (+/- 2 people). The reason why Scrum discourages very big teams is that as the team size grows, communication and co-ordination suffers. Big teams are also not as cohesive as small team and have a lesser sense of belonging. These qualities are very important for the Scrum approach to function well, hence, it is ideal to have small teams practicing Scrum.

ScrumMaster

ScrumMaster’s role is to train and guide the team, the product owner and the upper management in understanding Scrum and using it correctly. ScrumMaster thus helps successful practice of Scrum. (The Scrum community has over the last few years has matured in it’s understanding of the ScrumMaster role. No longer do experienced practitioners explain ScrumMaster in terms of project leader or manager. This in reality is a completely different role, and not a fancy title for Project manager.)

A good ScrumMaster protects the team from distractions and facilitates team’s work. Ultimately ScrumMaster does whatever is necessary for the team to succeed in meeting their Sprint commitments.

ScrumMaster is certainly not a manager in traditional sense. Team does not report to the ScrumMaster. ScrumMaster works alongside the team to make sure that the team delivers by removing impediments encountered by the team and interacting with Product Owner to make sure that maximum business value is delivered.

While transitioning from a traditional project setup to Scrum, a ScrumMaster can be chosen from any of the departments or roles like development, testing or product management. But, it is not advisable to have a project manager act as ScrumMaster. It creates a disincentive for team to communicate freely and honestly and problems are generally swept under the carpet in the presence of a manager, which is contrary to the aims and spirit of Scrum which is based upon self-organizing teams having freedom and responsibility to do work their way so that tasks can be accomplished. Micromanaging people and their work is against spirit of Scrum.

ScrumMaster and Product Owner being the same person is a Scrum anti-pattern. They have different responsibilities and the conflict of interest is very substantial. If same person is acting in both the roles, it may be possible that Product Owner role overrides ScrumMaster role and may start to influence the team to take on more than they can comfortably do and this may put the team in a situation where they may have to work at an unsustainable pace. This is a distinct possibility as Product Owner is in a way, representing the wants of the customers (not necessarily what is best for the customer) and would like to have as many features completed as possible.

Support and commitment to Scrum is of utmost importance for Scrum to succeed. ScrumMaster may have to push back on the amount of work that the team is committing to in a Sprint based on the team’s decision. It is also ScrumMaster’s duty to protect the team from outside influence from elsewhere in the organization so that work always flows through the Product Backlog maintained by the Product Owner and nowhere else. It is seen all too often that work can be assigned to the members of the team directly from someone high up in the organization without consultation or even knowledge of ScrumMaster. Upper management should understand that this is not how teams following Scrum work. For Scrum to work, ScrumMaster and the team should be empowered to take on work in a systematic manner. And it is very important for the upper management to understand this and respect the way the team and ScrumMaster work and not interfere in their way of working. Else, the results will be disappointing and generally Scrum takes the blame for failure. What needs understanding is that this way of working is not Scrum at all.

Now that we have described the participants in Scrum, we will describe how the Sprint starts and what are the activities that happen at the beginning, during and after the Sprint.

Sprint Planning Meeting (SPM)

Sprint planning meeting, as the name suggests is the meeting in which work for that particular Sprint is planned. The participants of this meeting are Product Owner, ScrumMaster and the team. The inputs to this meeting are the Product Backlog as maintained by the Product Owner and the available hours of the team members. The result of the Sprint Planning meeting is the commitment of the team to the Sprint goal which is agreed upon in the meeting. Sprint goal is made up of some of the high priority features for the product from the product backlog and it is to this goal that the team commits to for the duration of the Sprint.

There are two parts to the Sprint Planning meeting. In the first part of the meeting, what needs to be done during the Sprint from the Product Backlog is discussed and decided. The stress during this part of the meeting is on “what” portion of the Product Backlog. During this, Product Owner spells out and explains the features of the product which are top most priority from the Product Backlog. This meeting is a dialogue between the team, ScrumMaster and Product Owner about top priority features of the product. Through this dialogue, it is expected that the Product Owner will communicate his vision for the product and it’s features to the team for the current sprint.

Team along with Product Owner then decides what features it can take up for the current Sprint based on the perceived capacity of the team. Team also defines what is the definition of done for each of the features that they are going to undertake for the current Sprint. This is very important because it is all too often the case that there are varying versions of what does it mean when a task is said to be complete. The result of the first part of the Sprint Planning meeting is that the team understands the set of features with top priority from the Product Backlog and this is spelled out as goal for the sprint.

In the second part of the sprint planning meeting, how the goal for the sprint can be achieved is discussed. The stress in this meeting is on the “how” part of the goal. In this meeting the team discusses the features further and if necessary design the features at the top level to gain a better understanding of the work. The result of this exercise would be breaking down of the work into tasks. These tasks constitute the Sprint Backlog.

At this stage of the meeting, the tasks that are broken down are estimated for the number of hours it takes to complete these. Depending upon the number of hours available for team members, number of these tasks are committed by the team to Product Owner for completion. It is possible that at this stage, it may turn out that the team does not have enough capacity to complete all of the tasks. If this happens then the team renegotiates with the Product Owner and decides on which tasks to complete based on importance, complexity and estimates. The goal for the sprint can be restated based on these new findings.

After the tasks are finalized, the team commits to completion of these tasks. Once this happens, the tasks for that Sprint are fixed. Product Owner cannot request for addition of new tasks for that Sprint.

Product Backlog

Product Backlog is a prioritized list of features maintained by Product Owner. This is the list from which top priority features are taken up for development in Sprint. This backlog is constantly refined by the Product Owner as the project progresses. Some features may lose importance and they can be pushed down the priority order and some features may become important and some new features may be added as new ideas evolve to the top of the list.

Product Backlog Item

Description

Story-points

PB Item A

Description A

2

PB Item B

Description B

4

PB Item C

Description C

3

PB Item D

Description D

6

A sample Product Backlog is provided above. At it’s simplest, the backlog contains backlog items and their descriptions and any other relevant information about those items in a sorted order (we will describe the other two columns in later section). The ones on the top are high priority product backlog items. As we move lower down the table, priority decreases. Product Backlog is a dynamic entity and based on the inputs from various quarters, the backlog items can change at anytime. New items can be added if it is decided by the Product Owner that they are required for the product. These will have to be appropriately inserted in the list based on their priority. Any obsolete items will have to be deleted.

Since the most important features are the features that will be at the top of the list, these features need to be sketched out in detail and well thought by the Product Owner. While Sprint is ongoing, it is Product Owner’s responsibility to discuss with customers, product management and other stake-holders to find out what is important for the product and be able to articulate a well formed vision for the product in terms of well laid out, prioritized list of features that is Product Backlog. As Product Owner is the one and only point who decides what is important for the product to be successful, Product Backlog is the only place where all the requirements are captured as features.

There may be instances where the Product Backlog items under implementation in the current Scrum may become obsolete. In most cases, this may happen due to some unforeseen external stimulus. For example, the item under development in current sprint may become obsolete due to the fact that a third party utility or library becomes available which can replace the backlog item. Or customer may decide that that particular backlog item is no longer needed due to changed business requirements. In such cases where it no longer makes sense to implement the product backlog item, then that Sprint can be cancelled. A new sprint has to be planned in such cases, with newly prioritized product backlog.

Sprint Backlog

As discussed in the previous section, sprint backlog is derived from the product backlog in sprint planning meeting. A sample Sprint backlog looks like this.

Product backlog item

Sprint Task

Owned by

Estimated effort

Day 13

Day 12

Day 11

...

PB Item A

SB Item 1

Dev A

6

6

0

..

..

PB Item A

SB Item 2

Dev B

4

5

3

..

..

PB Item A

SB Item 3

Dev A

6

6

6

..

..

PB Item B

SB Item 4

Dev C

5

4

4

..

..

PB Item B

SB Item 5

Dev C

3

3

0

..

..

During the Sprint planning meeting, before the second part of the meeting starts, the product backlog items on which the team is going to work is known. During the second part of the meeting, these items are designed at a top level so that the next level tasks become clear. These tasks are called sprint tasks and they are tracked in a table called Sprint backlog. A sample sprint backlog in action is provided above for reference. From each product backlog item selected for the sprint, there will be at least one corresponding sprint backlog item. During the sprint planning meeting, number of hours of effort to complete these sprint tasks is estimated. This is considered initial estimate for these tasks. During the meeting, the team volunteers for the tasks based on the number of hours available to them during the sprint. Once sprint starts, these estimates are revised for the sprint backlog items or sprint tasks as team learns more about these tasks. At the beginning of the sprint, the number of hours left to complete the sprint backlog is sum of the initial estimates during the meeting. This number keeps getting revised and refined as the sprint progresses. And when a task is complete, the effort is marked as zero in the table. Each day of the sprint, the team meets for a short duration for a meeting called daily scrum after which the estimates for the remaining sprint backlog items are updated. These are summed up and this number is used to draw a chart called Sprint burndown chart.

Daily Scrum (Daily Stand-up)

When a Sprint is ongoing, team gets together and reports the progress and status to each other in a meeting that is held daily called Daily Scrum or Daily Standup Meeting. This meeting is called a Standup meeting as the meeting is not held in a conference room. It is held in a location where there is a wall on which the sticky paper slips can be stuck and the status of the work can be visually tracked. And the meeting is held while standing. It is to ensure that the meeting is kept short. A rough guideline is that this meeting should not be more than 15 minutes in duration. The agenda for this meeting is very simple. Each team member reports three things. What has been done yesterday? What is going to be done today? What are the impediments that he/she is facing in getting things done? No other matter is allowed to be discussed in this meeting. Once all members of the team report these three items of the agenda, the meeting is done. If there are any other things that come for discussion during the daily scrum meeting, they will have to be held and be discussed along with relevant people and ScrumMaster after the Standup meeting.

After the daily scrum is done, if there are any sprint items which are under progress or yet to be started and if they need re-estimation of effort, it is done. And these re-estimations are recorded in the same table which records the sprint backlog as well as show in the section sprint planning. Using these re-estimated hours left to complete rest of the sprint backlog, sprint burndown chart is drawn. Sprint Burndown Chart

The latest estimate of number of hours still needed to get the rest of the sprint backlog items done is calculated daily. This is plotted on a chart called sprint burndown chart. Sprint burndown chart is a graph which shows the reamining estimated hours of work on the y-axis and the elapsing time in the Sprint on the x-axis.

An ideal line (which is straight line in the graph below) is drawn from the point on y-axis which equals the initial estimate for the sprint backlog as estimated during the sprint planning meeting, to day zero on x-axis as shown in the figure below.

If the work in a sprint is progressing very well, then the sprint burndown curve would track the ideal straight line very closely. Each day, during the Daily Scrum, new estimates are given to the tasks which are ongoing and which have not been started yet. As tasks keep finishing, the time that was estimated for those times keep getting reduced on the curve and at the same time, for the unfinished tasks re-estimations are done on a daily basis as new learnings keep coming and new facts surface. At any given point in time, the burndown curve charts the projected amount of work still left. A curve with downward trajectory shows that the estimated remaining amount of work for sprint is reducing, which means that some work is being done which is contributing towards moving the sprint tasks to “done” state.

It is important to note that the sprint burndown chart just shows the estimated total amount of work left in the current sprint to finish all the sprint tasks and nothing else. There is a tendency to read too much into the data and the chart especially by managers who are used to command and control style of working. In fact this data sometimes is sometimes used to even do performance appraisals for individuals. It cannot be stressed more that this is not how to use this chart. If this is how it is going to be used, people naturally will start to massage data to show a nice curve pointing downwards by hiding the problems. The important part of scrum is to have transparency, which means if there are problems, then should be discovered immediately. Scrum is a framework which is the result of recognition that problems can and will occur and there is need to uncover them early enough so that they can be overcome. This is the reason why we have so many “inspect and adapt” points where we can correct our course of action to overcome problems.

Sprint Review

Sprint review is meeting that happens at the end of the sprint. For a sprint of four weeks’ length, this meeting can last for four hours. For shorter sprints, this can be shortened proportionately. The purpose of this meeting is for the team to get together with the Product Owner and other stakeholders who would be interested in the progress of the work, and demonstrate the working software. In this meeting, the work that has been accomplished is discussed in detail. Stock of number of completed tasks and uncompleted tasks is taken. They are also discussed along with details about whys and hows of what has been and what has not been accomplished. The challenges faced by the team during the sprint are also discussed in the sprint review.

Sprint Review meeting’s purpose is to inspect the work under progress. Once this is done, the completed work and incomplete work becomes clear along with challenges and difficulties in accomplishing these. The lessons learnt during the previous sprint are taken into account in this meeting and they are discussed so that the Product Owner, the team and ScrumMaster can take these into account during the sprint planning for next sprint.

Sprint Retrospective

Sprint retrospective also happens at the end of the sprint. Sprint retrospective is a different meeting than sprint review, though they may both sound similar. The purpose of sprint review is to review the work items under development during scrum. Whereas, in sprint retrospective, the stress is on the way of working and the practice of scrum. In this meeting, ScrumMaster and the team discuss what went well in the sprint and what did not go well in the sprint. The good practices are reinforced for continuation in further sprints. The problems and challenges are discussed and remedial steps are taken. Typically, the kind of things that are discussed during this meeting are the activities that are part of scrum practice, tools used by the team during the work, work practices, meetings and communication effectiveness etc. Aim of this meeting is to improve the effectiveness of scrum and way of working so that the team can work in a productive, pleasant and sustainable work environment.

Release Planning – Estimations – Story Points

Overview

Release planning covers long-term planning in the Scrum world. This is done so we can determine when we can deliver a given set of features (or release backlog) or how many features we can ready by a given date. Release planning works by averages and hence it is done deliberately at high level, without delving into detail. The approach in scrum is to let the team do the detailed planning always, sprint by sprint, and the long term-planning is done by the Product Owner (the Scrum-Master could help with the steps). In other words detailed planning of features to be implemented in future sprints is forbidden (Guessing how you’ll be spending your day two months from now is something of a fantasy – The Scrum Primer, Pete Deemer, et al). Release planning is closely related to estimation. Scrum doesn’t by itself mandate an estimation approach, however most Scrum projects use a story-point approach to estimation, which is explained in the next section. If your current estimation capability seems adequate, then you may continue with it. What is required is the ability to estimate the size of individual features, or stories, use-cases, or anything that is in the product backlog. However, in our experience very few projects have mastered estimation. Note the contrast between this approach to the traditional one, of trying to first having a detailed work breakdown structure and plan, then estimating effort required for each task by adding the efforts for all the tasks, and then working out the total time required by composing and aggregating all the task efforts at various levels appropriately. However if you are certain that your estimation is very good, you can skip the next section on story based estimation.

Story Point Estimation

Estimation in software industry has been a bugbear for a long time. Common shortcomings are

Story point estimation avoids these shortcomings, however it doesn’t by itself provide perfect predictability, it is still an estimation! Based on the wide-band-Delphi method, since this approach estimates size, the estimation of effort from size is automatically separated.

The whole team is involved in estimating the backlog items. A subset of the backlog (usually the top dozen or so items) is studied. A series is selected, usually the Fibonacci series. Some teams use 1,2,3,5,8,13 and 20; other teams use 1,2,4,8,16 and 32. Any item that is deemed to be larger than 20 or 32 should be broken down into smaller parts, since it is easier to estimate smaller items than larger items. Teams are allowed to choose only whole numbers which belong to the chosen series. This emphasises the fact that this number is only an estimate.

Here is how estimation is done. The team quickly selects the simplest item by consensus. Sometimes the team may be puzzled because two items may seem very simple, in which case an extended debate over which of the two simple items should be selected is not necessary, any one will do (a coin flip may help). This item is assigned a value of one. Then items from the top of the backlog are picked one after another. For each item the team decides size (from the series) of this item relative to the item with a value of one. This may involve some discussion and many Scrum teams use poker planning to do so. Poker planning is as follows:

This approach tends to unearth many assumptions people make while estimating items. It is also evident that here the estimation of size is a relative measure, not an absolute one (unlike function points for instance).

How Release Planning is done

First, the product backlog items are estimated in terms of size (not effort). This size measure could be Function Points, Use Case points or indeed any metric that represents the size of the functionality, or story points. Next, we have to know, the average capacity of a team ideally in terms of the size of working software created (again not effort), in a standard sprint. This capacity is called the velocity. The velocity can be worked out from historical data or simply be an informed (possibly gut-feel) guess. Now the product backlog can have a cumulative size (usually in points) against each backlog item. To find out which sprint a given item can be delivered, we need to divide the cumulative size by the velocity and round up the result to the next integer. We can easily see when each item can be delivered.

The projected progress and release plan can be represented visually on a “release burn-down chart”. This is very similar to the sprint burn-down chart. The Y-axis has unit of size markings, and the X-axis the sprint numbers, instead of hours and days respectively.

This is essentially the way in which Product Owner can plan a release. Of course this should involve a skillful use of buffers, because velocity is an average of what is delivered in a sprint, and not a prediction. The actual software developed from sprint to sprint will vary and deviations from the initially assumed velocity may be due to a combination of factors:

Since the success of release planning hinges upon the assumed velocity and estimation of backlog items, the teams ability to estimate is important. This is something that requires the team and Scrummaster to really pay close attention to. In cases where there is no historical data, there is no means other than to guess a velocity for a team. It is recommended that three to four sprints are done, and the velocity to be used in planning is based upon the results of these sprints.

Sl. No

Product backlog item

Story points

Cumulative

1

Create a product category, for internal consumption.

3

3

2

Delete product category

2

5

3

Update product category

8

13

4

Delete product category (cascade)

5

18

5

3

21

6

3

24

7

Publish product category

8

32

8

1

33

9

Aggregate product categories

1

34

10

Search for product category description

2

36

11

8

44

12

2

46

13

1

47

39

3

156

40

Merge product categories

8

164

If the team has a velocity of 13, then we can see that the first three items will get done in the first sprint, and the next three in the second sprint, but not quite the 7th item. The 10th item will get done in sprint 3 (cumulative points=36; 36/13= 2.77, i.e should be ready by end of third sprint).

Also if we have a two week sprint and the release is six months away, then we have 13 sprints in all. Keeping one sprint for last minute pre-release activity, it means we have 12 sprints, and 12x13=156 points can be implemented. Therefore we can do uptil item 39. Again there is no buffer at all, and unless this is a stable team this is not certain at all. All this assumes that the velocity is a known. However for teams just beginning Scrum, velocity would be a guess, and also remember that the velocity is an average. Teams may be having a gradually increasing velocity, especially if their improvement is real. There are teams which will be tempted to play the system, and assign higher story points to similar sized items. The answer to such behaviour is transparency engendered by trust.

Release Planning Summary

This section explained how a Scrum project is planned and monitored over the medium to long term. Yet again the approach is essentially “inspect and adapt”. Release planning is a higher level planning that works by aggregation and averaging. How estimation is done and used in release planning is an important aspect of release planning. It is worth noting the trite observation that estimation is just that, estimation, not prediction (however much one might wish otherwise) in or outside of Scrum. It does not mean that there can be no predictability, but just that there are limits, and without intelligent use of buffers it is very unlikely that project teams can consistently meet targets. [ As an aside, many project managers and teams give the impression that they meet targets consistently, this is often done by completing features shoddily, which necessitate significant effort for fixing defects. ]

Also we need to note that velocities are particular to teams and these should not be compared across teams in other words to compare teams (particularly if using story points as size units, since story points are relative).

Release planning steps summarised:

Home