Scrum Basics

INDEX

1. Agile Overview
1. Challenges in Traditional Software Development Model
2. Agile Landscape
3. Traditional Vs Agile Software Development
4. Scrum
2. Scrum Framework
3. Scrum Roles
1. Product Owner
2. Development Team
3. Scrum Master
4. Scrum Artifacts
1. Product Backlog
2. Sprint Backlog
3. Shippable Product Increment
5. Scrum Events
1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective
5. Product Backlog Refinement
6. Relative Estimation
1. Relative Estimation
2. Planning Poker Game
7. Release Planning
8. Distributed Scrum
1. Distributed Team Models
2. Challenges with Distributed Scrum
3. Totally Integrated Scrum

Scrum Events

All the Scrum Events are time-boxed events i.e. every event has a maximum duration. Once a Sprint begins, it’s  duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved.

Other than the Sprint, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something

Scrum has five events

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
• Product Backlog Refinement

Sprint

The heart of Scrum is Sprint - a Time-Boxed effort ranging from 1 to 4 weeks. As shown in the diagram above, it is an iterative development cycle. As Sprint is Time-Boxed, it cannot be extended than the planned end date, whether the work planned for that Sprint is completed or not. If work for some of the items planned for a current Sprint is not completed then those items are pushed for the next Sprints but the current Sprint is not extended. Also, no disturbances are allowed during the Sprint in terms of resources as well as the items selected for the Sprint. No new Items are added during the Sprint. Sprint embraces change for next Sprints. At the end of the Sprint, the Development Team delivers Potentially Shippable Product Increment. The Product Increment should be fully implemented, tested and free of known issues. It should be integrated and deployed on Production near environment.

Each Sprint may be considered a project with maximum a one-month horizon. Like projects, Sprints are used to accomplish planned tasks. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

Sprints are limited to maximum one calendar month. If a Sprint’s duration is too long, the definition of what is being built may change, complexity may rise, and risk may increase. Sprint gives an opportunity for an inspection and adaptation of progress toward a Sprint Goal at least every calendar month. It limits the risk to maximum one calendar month of cost.

Sprint Planning

The Sprint Planning meeting is conducted at the beginning of each Sprint. The work to be performed in the Sprint is planned at the Sprint Planning meeting. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning answers the following:

• What can be delivered from the upcoming Sprint?
• How will the work, needed to deliver product increment, be achieved?

Sprint Planning Meeting is divided into two distinct sub-meetings.

1. Sprint Planning Part One - What
2. Sprint Planning Part Two - How

Sprint Planning is a Time-Boxed event. Each part is time boxed to maximum 1 hour per week of Sprint. 

Participants for Sprint Planning Meeting are:

• Part One - Product Owner, Team, Scrum Master
• Part Two - Team, Scrum Master, Product Owner(Optional)

Sprint Planning Part One

In Sprint Planning Part One meeting, the Product Owner and the Team review the high-priority items from the Product Backlog that the Product Owner is interested in developing in the current Sprint. Usually, these items have been well-analyzed in a previous Sprint (during Product Backlog Refinement), so that at this meeting there are only minor last-minute clarifying questions. 

In this meeting, the Product Owner and Team discuss the goals and context for these high-priority items on the Product Backlog, providing the Team with an insight into the Product Owner’s thinking. Part One meeting focuses on understanding what the Product Owner wants and why those features are needed. At the end of Part One, the Product Owner may leave the meeting but make sure he must be available during Part Two of the meeting if there are any queries to answer.

Sprint Planning Part Two

Sprint Planning Part Two focuses on how to implement the items that the Team decides to work on. The Team selects the items they can complete by the end of the Sprint, starting at the top of the Product Backlog. It is the Team which decides how much work it can complete in a Sprint rather than somebody assigning the tasks to the Team. This is the beauty of Scrum. As the Team selects the items based on its analysis and capacity, it gives more realistic forecast of what can be delivered at the end of the Sprint. From the Product Owner’s prospective, as the Team is selecting items from the top of the prioritized Product Backlog, the Team will be working on the most important items. Team can also select some of the lower priority items if they think that they have some capacity and these items can easily fit. In this scenario the Product Owner is consulted before adding lower priority item to the Sprint Backlog.

The Product backlog items selected for the Sprint are called Sprint Backlog. Team pulls items from the Product Backlog into Sprint Backlog until Sprint Backlog is full. The Sprint Backlog also contains defects and unfinished work of previous Sprint.

In this meeting, the  Team does designing and planning of the tasks needed to convert the Product Backlog into a working product Increment.

By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Product Increment.

During this meeting Sprint Task Board is updated with the User Stories and the tasks to be worked on for the planned Sprint.

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development the Team is to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next Daily Scrum. The Daily Scrum is held at the same time and same place each day to reduce complexity. During this meeting, the Development Team members answer three questions

1. What has been completed since the last meeting?
2. What will I be doing today?
3. What are the impediments in my way?

The Development Team uses the Daily Scrum to inspect progress towards the Sprint Goal and towards completing the work in the Sprint Backlog. All the Team members attend this meeting. To keep it brief, it is recommended that everyone remain standing.

Daily Scrum is not a Status Meeting where everyone gives a status to Scrum Master. It is an opportunity to discuss the progress towards the Sprint Goal and impediments if there are any. One of the team member or the Scrum Master makes notes of the impediments and the Scrum Master is responsible to help the Team on these impediments. Apart from the above mentioned questions, there should not be any in-depth discussion. If detailed discussion is required then separate meeting is scheduled. During Daily Scrum Meeting, Team updates the Sprint Task Board and Burndown Chart.

Here are some of the guidelines for Daily Scrum Meeting.

• The Team should not report to one person  i.e. Scrum Master 
• Talk Loudly 
• Run at the same time everyday
• Start on time
• Always run it
• Keep to the point
• Keep it short

Tracking the progress during the Sprint

The Scrum team is self-managing and in order to do this successfully it must know how it is doing. Every day the team members update their "hours remaining to complete their task" in Sprint Backlog. One Team member adds up the hours remaining for all the team members and draws a Burndown Chart. The Burndown chart has two lines, one ideal line and the other actual line. The Ideal line shows the Ideal Efforts Remaining for each day to complete the Sprint tasks. This line moves downward and ideally on the last day of the Sprint it reaches to "Zero Hours Remaining". The Actual Efforts Remaining line shows the Actual Efforts Remaining to complete Sprint Tasks. If this line is below the Ideal Efforts Remaining line then the Team is performing well and will complete the Sprint Backlog Items on or before the Sprint end date. If the actual line is above the ideal line then the Team is not doing well and Team may not complete all the Sprint Backlog Items on the last day of the Sprint. In the second scenario, the Team has to take corrective measures so that it can achieve the Sprint goal. The important point of Burndown Chart is that it shows the progress of the Team not in terms of the “hours spent by the Team” but in terms of the “hours remaining to complete the tasks”. If the Team is using some tool to track its efforts then the tool generates the Burndown chart automatically.

Sprint Backlog:

Sprint Burndown Chart:

Burnup Chart

There is one more chart to track the progress of the project towards completion – the Burn up Chart. Typical the Burn up chart has two lines.

1. Total Work Line(Total Scope)
2. Work Completed Line

In this chart the vertical lines represent the total work. In Scrum it is measured in terms of Story Points. The horizontal line represents the time generally in terms of number of days. The total scope line represents the total scope of current Sprint and the work completed line represents the work completed on each day. The distance between these two lines is the amount of work remaining for the completion of Sprint. When these two lines meet, the Sprint will be completed. Regular monitoring and analysis of this chart helps you to identify the problems and take corrective action. 

Sometimes a third line is added to this chart – the Ideal line. This line shows ideal work to be completed for the completion of project on a given date. If the actual line is above the ideal line then your project is ahead of the schedule and when the actual line is below the ideal line then your project is behind the schedule.

If you are using a tool like the Jira to track your project efforts then these tools can create Burn up chart for you.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Product Increment and adapt the Product Backlog. During the Sprint Review, the Scrum Team and stakeholders discuss about what was done in the Sprint. This is an informal meeting, not a status meeting. It is an opportunity for the Product Owner to review the Product Increment and give feedback. It is the time for a Product Owner to understand what is going on at the Development side and for the Team to understand what is going on with the Product Owner and Business side. An Important element of the Review is an in-depth conversation between the Team and the Product Owner. While inspecting the product increment there should not be a slide show but the actual hands on the product increment by the Product Owner or end user. 

Duration of this meeting is one hour maximum per week of Sprint.

Sprint Retrospective

The Sprint Review inspects and adapts the Product Increment whereas the Sprint Retrospective inspects and adapts the process and the environment. During this meeting three questions are asked with respect to the process.

1. What is working well?
2. What is not working well?
3. What are the Action Items for future Sprints?

The Scrum Master facilitates this meeting but many a times it is recommended that the Scrum Master from the other team facilitate this meeting.

By the end of the Sprint Retrospective, the Scrum Team should identify the improvement areas with respect to the process. Those improvements should be implemented for next Sprints - inspection and adaption at the process level. Though the improvements can be implemented at any time, the Sprint Retrospective is a formal opportunity for inspection and adaption process.  

Duration of this meeting is 45 minutes per week of Sprint.

Product Backlog Refinement (Backlog Grooming)

While working on current Sprint Items; some percentage of the Sprint time should be dedicated to refining (or “grooming”) of the Product Backlog items. The Backlog Refinement includes detailed requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. The Backlog Refinement should be conducted near the middle or end of the Sprint, so that the Team, the Product Owner and other stakeholders have additional information to update the items in the Product Backlog.

This refinement activity is not for the items selected for the current Sprint; it is for the future items, most likely in the next one or two Sprints. 

Duration of this meeting should be no more than 10% of the total capacity of the team for that Sprint. 

Activities performed in this meeting are 

• Ensure the backlog is DEEP
• Re-estimate User Stories
• Update User Stories with new details
• Split User Stories into smaller ones
• Discuss technical risks
• Re-prioritize the items in Product Backlog

Scrum Artifacts

Scrum has three Artifacts.

1. Product Backlog
2. Sprint Backlog
3. Product Increment

Product Backlog

Product backlog starts with Product Vision. Product Backlog is an ordered list of customer requirements and a single source of requirements for the given product i.e. there is only one Product Backlog for a product under development. Product Owner is responsible for the Product Backlog.

Product Backlog is never finalized. It continuously evolves as the product and the project environment evolves. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that needs to be developed for the product release. Product Backlog items have the attributes of a description, order and estimate.

The high priority items in the Product Backlog are fine grained and have more details as well as accurate estimates because of the greater clarity and details of those items. Items on the lower priority are big items with high level estimates. As Team gets more clarity on lower priority items, these items are further split in to small items. The Development Team is responsible for the estimates of the items in the Product Backlog.

Product Backlog is DEEP

DETAILED APPROPRIATELY: 

The top priority items of the Product Backlog are more fine-grained and detailed than the lower priority items, since the former will be worked on sooner than the latter. 

ESTIMATED: 

The items in the Product Backlog are estimated. The items at the top of the backlog have more accurate estimates. The lower priority items are estimated at high level and can be re-estimated as team gets more information.

EMERGENT:

Product backlog is regularly refined as the Team learns and gets more information. Each Sprint, items may be added, removed, modified, split, and changed in priority.  Thus, the Product Backlog is continuously updated by the Product Owner to reflect changes.

PRIORITIZED:

Items in Product Backlog are prioritized or ordered in 1-N order. The Higher priority items should give more value than the lower priority items. Priority of items can be changed over a period of time

User Story

User Story is a short description of a requirement from user prospective. It is not a requirements document. It clarifies what the user will get. It represents a small feature that can be estimated and developed independently. It contains business requirements that have a high level description of a required functionality.

The User Story template should be like 

As a <role> I want <a feature> so that <reason, value>

Example - As a user, I want to cancel hotel reservation so that I can get a refund.

INVEST Model

User stories follow INVEST Model.

I – Independent: Should be self contained 

N – Negotiable: Up until they are part of Sprint, can always be changed and re-written

V – Valuable: Must deliver a value to a end user

E – Estimatable:  Team must be able to estimate the size of a user story

S – Small: Should not be so big as to become impossible to plan/task/prioritize with high degree of certainty

T – Testable: Must provide the necessary information to test it after development

Example of an User Story

As a user, I want to cancel a hotel reservation so that I can get a refund.

• A premium member can cancel on the same day without a cancellation fee
• Non-premium member is charged for the same day cancellation with a 10% cancellation fee
• An email confirmation is sent to the customer
• The hotel is notified of the cancellation
• Reservation can be can cancelled a  day before by all the members without any cancellation fee

USER STORIES ARE VERTICAL

Bad User Story

Good User Story

User Stories should be vertical. There should not be separate User Stories for User Interface, Business Layer and a Database. A Good User Story should cover all areas including User Interface, Business Layer, Data Access Layer and a Database. 

Sprint Backlog

Sprint Backlog is a subset of Product Backlog. The items in the Sprint Backlog are selected by the Development Team and it is a forecast by a Development Team about what functionality will be delivered in next Product Increment. It also contains defects and unfinished work. Each item in Sprint Backlog should be small enough so that it can be delivered in a sprint. A general guideline is to complete it in ¼ th or less of sprint of the whole team. Once the Sprint starts there should not be any changes in Sprint Backlog items. If the new requirements emerge during the Sprint then those requirements should be added to the Product Backlog but current Sprint Backlog should never change.

Product Increment

The Product Increment is the sum of all the items completed during a Sprint and the items completed in previous Sprints. Each Product Increment is additive to all prior increments and thoroughly tested, ensuring that all the increments work together. At the end of Sprint, the Product Increment must meet the definition of "Done" agreed by the Scrum Team. The Product Increment must be in "Ready to Ship" condition. 

Definition of Done

It is a list of requirements that software/user story must adhere to for the team to call it complete. While the DoD usually applies to all items in the backlog, Acceptance Criteria are applicable to a specific user story. In order complete the story; both the DoD and acceptance criteria must be met. Unless this list is done the Product Increment is not done. Before the start of the Sprint the Product Owner and the Team should agree on Definition of Done. It should not be changed during the Sprint. If changes need to be done then it should be done between Sprints.

Example of DoD

• Code builds without warnings
• Code unit tested
• Deployed to system test environment and passed system tests 
• Build pushed to demo server

Scrum Roles

In Scrum there are three roles - Product Owner, Development Team and Scrum Master. Together these are known as the Scrum Team.

Product Owner

A Product Owner has a vision. The vision could be anything like “sending a space ship to Mars by the end of Dec. 2014” or “developing a touch screen cellphone with certain features”. For an internal project, the Product Owner and the Customer could be the same. For some projects, he could be representing millions of people. In these  types of projects, the Product Owner is similar to the Product Manager of product organizations. But in Scrum, the Product Owner is different than the traditional  Product Manager. The Product Owner is more involved in the development process where as the Product Manager delegates the development tasks to the Project Manager. The Product Owner is responsible for maximizing return on investment (ROI) by identifying the product features, translating these features into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list. It is important to note that in Scrum, there is one and only one person who serves as – and has the final authority – the Product Owner, and he or she is responsible for the value of the work

The Team (Development Team)

The Development Team builds the product as per the Product Owner's vision. The Team in Scrum is cross-functional - it includes all the expertise needed to deliver a potentially shippable product increment. Development Team is also self-organizing and self-managing. It does not require a Project Manager or a Leader to manage itself. In Scrum there is no hierarchy of roles. All the team members are at the same level and are called simple team members. The Development Team is also a multi-skill team. Each team member has one primary, secondary and tertiary skill. All the team members are ready to learn newer skills and are always ready to help the Team to deliver potentially shippable product increment. The Development Team is Autonomous, it has freedom to govern itself and take decisions for its own. The Development Team is accountable for its deliverables. 

The Team size in Scrum Team is seven plus or minus two. For Software Development projects, it has different skills like Analysis, Design, Development, Automation, Testing etc. All the Team members are full time members. It is not expected that one team member is allocated partially to two different teams. In Scrum it is advised to have a co-located team for close coordination. But on account of Business reality,  we now have distributed Scrum Teams. It is also expected that there won't be any change in the Team during the Sprint. It is advised to continue the same team for multiple Sprints to achieve better results.

Scrum Master

The Scrum Master helps the Scrum Team to learn and apply Scrum principles to achieve business value. The Scrum Master does whatever in his capacity to help the Team, the Product Owner and the Organization to be successful. The Scrum Master is not a Project Manager. His role is of a facilitator or a coordinator. The Responsibilities of a Traditional Project Manager have been divided and reassigned to different roles in Scrum - mostly to the Team and the Product Owner. As a Scrum Master is not a Project Manager or a Leader, he does not assign the tasks to the team members or tell people what to do. He rather acts as a Scrum Coach and a Teacher. In this role, he helps the team to learn and apply Scrum Principles. In his role, he helps the team to remove the impediments and protects the team from outside interference. It is recommended to have a full time dedicated Scrum Master. In a small team one of the team members can play a role of a Scrum Master.

The Scrum Master and the Product Owner cannot be the same person as their primary focus is different and combining these two roles might lead to conflict. If a Product Owner is performing the role of a Scrum Master then it might lead to a situation of micro-managing Product Owner.

Scrum Framework

Scrum is a development framework in which the cross-functional teams develop products or projects in an iterative, incremental manner. It structures development in cycles of work called Sprints. These iterations are one to four weeks each and take place one after the other without break. The Sprints are time boxed – they end on a specific date whether the work has been completed or not, and are never extended. Usually Scrum Teams choose one Sprint length and use it for all their Sprints until they improve and can use a shorter cycle. At the beginning of each Sprint, a cross-functional Team selects items (customer requirements) from a prioritized list. The Team agrees on a collective target of what they believe they can deliver by the end of the Sprint, something that is tangible and will be truly “done”. During the Sprint, no new items are added; Scrum embraces change for the next Sprint, but the current short Sprint is meant to focus on a small, clear, relatively stable goal. Every day the Team gathers briefly to inspect its progress, and adjusts the next steps needed to complete the work remaining. At the end of the Sprint, the Team reviews the Sprint with stakeholders, and demonstrates what it has built. The Team obtains a feedback that can be incorporated in the next Sprint. Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.

Scrum roles, artifacts, and events are summarized in a diagram below:

The core of Scrum is “inspect and adapt”. As the development involves learning, innovation, and surprises, Scrum emphasizes taking a short step of development, inspecting both the resulting product and the effectiveness of current practices, and then adapting it for the next development efforts.

Scrum is a Framework. As in traditional building structure, the framework does not define the interiors; Scrum left the detailing of this framework to the Development Team. 

Scrum Framework has Three Roles, Three Major Artifacts and Five Major Events.

Three Roles

• Product Owner
• Development Team
• Scrum Master

Three Artifacts

• Product backlog
• Sprint backlog
• Shippable product increment

Five Events

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
• Product Backlog Refinement

Agile Overview

Challenges in Traditional Software Development Model

The Traditional software development model follows a sequential life cycle called "the waterfall". The Waterfall model has different distinct phases like Requirements, Analysis, Design, Coding, Testing and maintenance.

In this sequential flow the duration of a project is very long ranging from few months to few years. The end user is not able to test the product till the end of project and at the time of user acceptance testing the end user finds that the product is not delivering the functionality what he was expecting.
There is a famous Swing Cartoon which shows comically what the customer is expecting and finally what the development team delivers.

Some of the limitations of the Traditional Waterfall Model are:

• Sequential flow: The model implies that you should complete the current project stage before you move on to the next stage. It neglects the fact that the requirements are continuously changing. 
• Delayed feedback: The Customer cannot test the system until the entire system is complete. Because of this, the team gets the feedback at the end of the project. After customer feedback, if there are any changes, the cost of change is very high.
• Learning not used for the same project: On completion of projects, many a times, the team feels that if it does the same project at another time, it can be done in a better way. The learning of the project might be used for the next project but the waterfall model does not have an ability to use the learnings for the same project.

Agile Landscape

To overcome the challenges of the traditional software development methods, by late 1990, many people around the world started developing software by using alternative methods which were not rigid and had  the ability to “review-act” fast to the changes in the requirements and technologies. The results of these new methodologies were very successful as compared to the traditional software development methods.

In February 2001, seventeen people met at Snowbird, Utah to discuss and try to find a common ground on these alternative methods. In this gathering, these people came up with the "Agile Software Development Manifesto".

The term "Agile Software Development" emerged from this meeting. This term was used as an umbrella referring to a family of emerging lightweight software development methods such as Scrum, Extreme Programming, DSDM (Dynamic Systems Development Methodology), FDD (Feature Driven Development), Crystal, and Adaptive Software Development.  Instead of emphasizing up-front planning and detailed requirements, these methods placed significant emphasis on continual planning, empowered teams, collaboration, emergent design, a test-early, and, most importantly, the frequent delivery of working software in short and rapid iterations.

Traditional Vs Agile Software Development

If we compare Traditional Development Projects Vs Agile Development Projects

Traditional Projects

• It assumes that full scope is known at the start of the project
• The Project length is over an extended period
• All tasks can be put in defined WBS
• The Process is sequential
• Stable requirements
• Detailed documents
• Rigid change control

Agile Projects

• Scope is partially known at the start of project
• The Project length is over a short period of time
• The Process is iterative 
• Emergent requirements
• Just enough documentation
• Effective change control

Driving Through a Traffic

The differences in these two approaches can be better explained with an example of a person driving through the city traffic. If a person makes a very rigid plan of his travel like the Traditional Software Development method, it might take a lot of time for him to reach his destination. There could be difficulties in his travel which may require a change in his route but if he decides to stay with his earlier plan then he may not reach his destination. Normally, while driving, we don't make a rigid plan. As we drive, we analyze the situation and make minor changes in our driving plan. The Development Team should adopt similar approach for a development project. The Software Development Method should be flexible enough to make changes in our plan as the situation demands.

Scrum

Scrum is an Agile framework for developing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex scope of work.

When Jeff Sutherland created the scrum process in 1993, he borrowed the term "Scrum" from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare the high-performing, cross-functional teams to the scrum formation used by the Rugby teams. In rugby football, a scrum refers to the manner of restarting the game after a minor infraction..

Deming Cycle

The Deming Cycle is the core of Scrum. In Scrum, the team follows a “Plan-Do-Check-Act” cycle in small iterations

Distributed Scrum

Nowadays many organizations are following the Scrum methodology for software development projects. One of the principles of Scrum is to have a co-located team for better communication and increased productivity. But because of their business needs, many organizations have teams distributed across the globe.

Business Need

The key advantages of having distributed teams are:

• Lower Cost of Labor
• Capture of talent which is not available locally
• Ramp down of vendor Project Team without layoff

In a traditional approach, team located at one location works on a specific functionality of the application. Ramp down of offshore team usually results in loss of critical knowledge on the area on which that team was working. Special efforts have to be taken to transfer that knowledge to the onsite team before the ramp down. Many a times the fear of this loss of knowledge influences the decision of offshorization. But if team follows the Totally Integrated Scrum model, where resources working on different locations work on all the functionalities, then knowledge resides  at all locations. In the next section we will discuss the Totally Integrated Scrum model in detail.

Distributed Team Models

There are three different models for distributed teams.

Isolated Scrums – In Isolated Scrums, the teams are isolated across geographies. In many cases, only the onsite teams are following the Scrum and the offshore teams are following the traditional waterfall model. In this scenario, the velocity of the offshore team is very less as compared to the onsite team, which causes overall less velocity of the entire team. This model is not recommended for Distributed Teams.

Distributed Scrum of Scrums – In this model, the work is partitioned across cross-functional, isolated Scrum Teams by eliminating dependencies between the isolated teams. Isolated teams are interlinked by Scrum of Scrums where Scrum Masters from the isolated team meet regularly to exchange the updates of their Scrum Teams.

Totally Integrated Scrums –The Totally Integrated Scrum model has fully distributed teams with members of each team located at multiple locations. While distributed nature of this model may create communication and execution challenges but by having Daily Scrum Meetings and using good communication practices one can overcome these challenges.

The Totally Integrated Scrum Model is the recommended model for experienced Scrum teams at multiple locations.

Challenges with Distributed Scrum

While there are many advantages of having Distributed Scrum Teams, there are certain challenges, which need to be addressed for successful execution of the project. Some of the challenges are:

• Communication
• Building Trust
• Overlapping Hours

Communication

Effective communication is the most important factor in delivering quality software. 

When an idea is generated at business, it is communicated to the development team. The development team asks questions and gets a feedback from the Product Owner. If there is a misunderstanding of a requirement then the product developed by the development team will not give complete business value. The cost of fixing the issues of a delivered product is very high.

In a distributed environment where Product Owner, Scrum Master and the Development Team are located at different locations, the team faces many challenges in communication. For example if the Product Owner is not available for query resolution then the Team has to wait and this waiting time affects the team’s velocity. So special efforts have to be taken to make sure there is effective communication between all the stake holders.

There are various modes of communication e.g. Face to Face communication, Telephonic communication, Emails etc. If we place these modes of communications on richness scale, richness of communication of each method will be as mentioned in the diagram below.

In general practice, email is the primary mode of communication. But if you see the above diagram, it is at the bottom of richness scale. The discussion which might take 5 minutes of verbal communication might need back and forth 10 emails. Therefore the Scrum Master should educate the team to move away from email communication and adopt the direct conversation.

In a distributed model there might be a case where the Product Owner is not always available to the offshore team. So the Product Owner should make himself available to the offshore Team in the overlapping hours. He should communicate to the team that it is okay to call him without a pre-scheduled meeting. His phone number and availability hours should be placed on wiki. In fact, the phone numbers and availability of hours of all the team members should be published on Wiki as well as should be placed on the desk of each of the team members.

The Team should be equipped with high quality communication equipment. Every team member should be equipped with a high quality speaker phone as well as Skype on his desktop. It will help all the team members to communicate with each other by audio-video conference. The problem with Audio only mode is that the facial expressions as well as body language is missing and the body language plays a very important role in our communication.

A High resolution Video Conference facility should be available at all the locations. All the important Scrum Events like Sprint Planning, Sprint Review, Retrospective, and Daily Scrum should be conducted using the Video Conferencing facility.

In addition to the Video Conferencing facility, it is recommended to have an “Always on Skype Video Streaming” at two locations. It will act like a window between the two locations. As it uses Skype, it is a low cost solution.

Sometimes there is a resistance from the Senior Management on the investment of these equipment. But if we consider the overall cost of the project then the cost of these equipments would be hardly 1% of the total cost of the project.

Building Trust

Another critical factor in the success of a project is Transparency and Building a trust between teams at different locations. This trust can be built by more human interactions. In a Distributed Team model there are many chances of misunderstandings and miscommunications. If there is a strong human bond between team members at different locations then these things will be taken as a regular miscommunication incident but if there is no human bond then these things might be considered as an evidence of incompetency of the other side. So building one to one connection between Distributed Teams is the most important activity.

At the beginning of a major project, it is recommended that the Product Owner and the Scrum Master travel to offshore for the duration of 1-2 Sprints. During this visit, the Product Owner can give details of Overall Vision, Purpose and Goals of the project to the Team. It will set a strong foundation for the team’s day to day work. This is an opportunity for a Product Owner and Scrum Master to understand the team and the challenges the team faces from the other locations. For a team, it will be a chance to build a one to one connection with the Product Owner and the Scrum Master so that in future the team won’t hesitate to communicate with them openly.

Along with the Product Owner’s visit to offshore, it is also recommended that the offshore team travel to onsite for 2-3 Sprints. This visit will give an opportunity for the offshore team to understand the customer environment and establish a personal bond with the onsite team members.

It is also recommended to have an offshore ambassador at onsite. This person will be a link between the offshore team and the onsite team. It is recommended to keep this position rotating so that many offshore team members will get an opportunity to work closely with the customer.

The second part of building trust is developing an Openness and Transparency. The Offshore teams are often fearful about being open to the onsite Product Owner. The Team fears that if they raised a concern then the onsite Product Owner will be upset and might complain to the Senior Management. There is also a fear that if they ask too many questions then they will be perceived as incompetent. As a result many questions go unanswered and the team makes assumptions. These wrong assumptions cause the delivery of wrong product.

To avoid these problems, the Product Owner/Scrum Master must communicate to the team that he would like to hear good news as well as bad news. It is always better to give bad news early so that corrective action can be taken in time.

Overlapping Hours

It is recommended to have some overlapping hours between the Distributed Teams. These overlapping hours will give an opportunity for the team members to interact with each other directly instead of only through emails. It is recommended to schedule all the major Scrum Events like Sprint Planning, Review, Retrospective and Daily Scrum during these overlapping hours. It is also recommended to use Video Conference for all the major meetings. Apart from Daily Scrum, the other meetings are longer and will need more overlapping hours. Meetings should be scheduled in early morning hours of the onsite team and early evening hours of the offshore team. So that only one side need not to stretch. If possible Planning Meeting 1 and 2 should be scheduled on two different days.

There are two scenarios of overlapping hours.

• Onsite teams located in Europe
• Onsite teams located in USA

 For a project where onsite team is located in Europe, there is a moderate overlap of working hours with offshore team in India. The Team can manage Daily Scrum meeting without difficulty but other meetings can stretch beyond the normal working hours. On these days, special transport can be arranged for the offshore team so that the offshore team can start their day late and stay late in the office. As there are only 3-4 long events in each Sprint, it won’t add much burden to the team.

For a team where the onsite team is located in US, there are some challenges in Overlapping Hours. But it can be addressed by changing the working hours of the offshore team. The Offshore team can start their day a little late and stay late in the office. In one of our projects the offshore team was starting their day at 10.30 in the morning and was working till 7.30 in the evening. This allowed around 2-3 hours of overlap between the onsite and offshore teams. On the days of long Sprint Meetings, special travel arrangements were made so that offshore team could stay late in the office.

Totally Integrated Scrum

There are three roles in Scrum – Team, Product Owner and Scrum Master. In a Totally Integrated Scrum model, special efforts need to be taken to make sure that all these roles at different locations work as a single integrated team.

One Team Engagement Model

Though the team members are located at different locations it should be treated as a single team. There should not be any differentiation between the onsite team members and the offshore team members. Special efforts should be made to make sure that the onsite as well as the offshore team members get a chance to work on all the functional and technical areas. This will help to retain the knowledge within the team if team at one location is ramped down.

Product Owner

It is recommended to have only one Product Owner for a Scrum Team located at multiple locations. Some teams have a “Proxy” Product Owner but many times the Proxy Product Owner does not have the depth of knowledge as of the “Real” Product Owner. It might create a confusion and sometimes the decisions made by the Proxy Owner needs to be reversed after a discussion with Real Product Owner. Offshore team can have domain experts who can guide rest of the team members in absence of Product Owner but there should be only one authority that will make the final decisions. In a Distributed Team there are less overlapping hours between teams at different locations. So the Product Owner needs to make his time available for question-answers during the overlapping hours.

Scrum Master

In a Distributed Team model, the role of the Scrum Master is more challenging and he needs to be involved more actively in team’s day to day activities. As there are more impediments and challenges due to the nature of the distributed team, the Scrum Master has to allocate more time to resolve these impediments.

In a Distributed Team model, the Scrum Master is located at one location and should be available to a team at different location in overlapping hours. In this scenario, the Scrum Master will be able to help the team on certain type of issues but most of the time when a remote team is working, he may not be available to help them on their day to day issues. So it is recommended to have a Secondary Scrum Master at a remote location. One of the team members from the remote location can play the role of a Secondary Scrum Master. The Secondary Scrum Master may not replace the Primary Scrum Master but he will certainly help the team to resolve day to day impediments.

Team Meetings

As discussed in the Overlapping Hours section, Daily Scrum should be organized at early morning of onsite team and evening time of offshore team. All the team members from different locations should attend this Daily Scrum Meeting. This meeting is an opportunity for team members from different locations to connect with each other. It is recommended to conduct this meeting through Video Conference.

Apart from this common Daily Scrum Meeting, it is recommended to have a Daily Scrum Meeting at a remote location at the local morning time. It helps team to remove local impediments.

For the team meetings which needs more time, the team can adjust the working hours on that particular day so that there will be more overlap between teams at different locations.

Use of Tools

In a Totally Integrated Scrum it is expected that all the team members are working on a Single Product Backlog and have only One Code Base. Also it is recommended to have a common wiki to share knowledge among the team members. Continuous Integration plays a vital role in Scrum, so team should use Continuous Integration Tools. Continuous integration will help to identify the problems early and fix them immediately.

There are many tools available in the market which will help the team on the areas mentioned above.

Conclusion

While Scrum recommends co-located teams but it is a business reality to have Distributed Teams. By implementing good engineering practices and excellent implementation of Scrum practices, it is possible to achieve same level of velocity and quality from Distributed teams as co-located teams. The entire team must function as a single team with a single Product Backlog, single code base and single reporting mechanism. Totally Integrated Scrum is the recommended model to utilize the full potential of remotely available talent.

Relative Estimation

In a traditional software development method, estimations are done in absolute number like hours or days. In this approach, by applying the Work Breakdown Structure, a big project is divided into small tasks and each task is estimated in hours. These estimates depend on the skills of the resources.

Estimation of technical tasks in absolute number is not always easy. Sometimes for a technical task, debugging will take 6 hours but the actual code fix will be done only in 10 minutes.

Relative Estimation could be useful in estimating complex tasks. To understand more on relative estimation, let’s take an example of buckets mentioned in the picture below.

If we ask how big is the first bucket and how big is the second bucket (absolute estimate)? We may not answer this question in absolute numbers. But if we ask the question, “How much bigger the second bucket is as compared to the first one (relative estimate)?” Usually we will be able to answer the second question more quickly and in a better way. It is better to use the relative estimation technique for estimating complex tasks.

Here are a few more examples of relative estimates.

• Australia is about the double the size of India.
• Canada is three times the size of India.
• Canada and USA are of the same size.

Relative estimates do not have units. They are just relative numbers. In Scrum these numbers are called Story Points.

In Scrum, Fibonacci numbers are used for relative estimation. What is Fibonacci numbers? Fibonacci is a series of numbers where next number is calculated by adding the previous two numbers.

Fn = Fn-1 + Fn-2

Here is an example of Planning Poker Cards (Fibonacci numbers) used in Agile Estimation

One may ask why Fibonacci number? Why not linear numbers?

Let's take an example of a Duster of white board. If we ask our team to estimate the size of Duster in inches, we will get answers from different people in a close range of 5 to 8 inches. After some discussion, the team may agree on 6 inches. But if we ask the same team to estimate the height of the roof of our meeting room in inches then the estimates might vary by large numbers. Some might estimate it as 80 inches whereas some might estimate it as 120 inches. But if we ask our team to use the Fibonacci numbers mentioned above then most of them will pick the number 100. Fibonacci numbers are more suitable for estimation of large tasks where we don’t have enough details on that task.  

One important point to note in Relative Estimation is that Relative Estimation numbers does not change by applying more skilled resources or by using tools to accomplish tasks. Let's play another game to understand this concept.

Add caption

Let's assume that you have three piles of stones of different size as given in the diagram above. Now let's estimate the relative size of a single stone from the first pile. As it is a small stone and there might be even a smaller stones, we can estimate the size of this stone as "2". Now consider the stone from first pile as a reference stone and estimate the relative size of stones from other two piles. After some discussion we can agree on the size of each stone as 5 and 13 relative to the size of a stone from the first pile. The total size of all the stones is 10*2 + 3*5 + 2*13 = 61.

Now in the first week a team has been given the task of moving all these stones by using their hands from one part of the city to other part of the city. Resource has to travel on foot. Probably the team will move all the stones by the end of week one. The actual efforts completed by the Team would be 61. This number is also called the Velocity of that team. 

V1 = 61 

Velocity - Total number of Story Points of all the stories done per Sprint. 

Now in the second week the supervisor asks the team to increase their productivity. In this week he gave them an additional task. Once the team completes moving all of the stones from these three piles then the team is asked to move back these stones to its first place. In this week, the team is allowed to use skilled resources as well as some tools. Now the team has knowledge of the first week as well as the tools and skilled resources. So in the second week the team will achieve higher number say 85. 

V2 = 85

In the third week the team is allowed to use some vehicle for transportation along with skilled resources. In this week, the team will achieve even higher numbers. Let's assume it as 153

V3 = 153

In this example, the size of stones does not change by the application of skilled resources or a transport mechanism. It remains the same. The change is in the total productivity numbers achieved per iteration i.e. Velocity.

As you see in this example we do not have to re-estimate the size of these stones for each iteration Also while estimating, we are not estimating the single “Time Value” to complete the task. Time value comes into picture by combining the Size, Velocity and Length of Sprint.

In real life software development, when the team is doing relative estimation then it does not matter whether they have prior experience of doing similar work or not.  As  you get more experienced or more skilled resources then you will achieve more velocity. Relative estimates remain the same.

Planning Poker Game in Scrum
Now let's discuss the steps of the game of Planning Poker used for relative estimation. 

Steps for the planning poker game

1. Select a reference story from the Product Backlog and estimate it in terms of Story Point.
2. Select another User Story from the Product Backlog for estimation
3. Understand the story from the Product Owner
4. Each person estimates the size of this User Story relative to the Reference Story using poker cards
5. Everyone shows their cards at the same time.
6. If estimates vary significantly, high and low estimators explain briefly.
7. Repeat up to three times or until team agrees to  the estimates
8. Pick a number that everyone agrees upon
9. Repeat this process for all the User Stories from the Product Backlog.

The important point over here is the resulting discussion.

Why Planning Poker Works?

• Those who do the work, do the estimation
• Team member has to give the reason for his estimation
• As team of resources do the estimates, it leads to more precise estimates.
• Each team member will be heard

Release Planning

How the Release Planning in Scrum is different from a Traditional Waterfall Model?

In a Traditional Waterfall Model, once we start the project, three factors are fixed - Time, Cost and Scope. But in Scrum the Scope is evolving as we progress and Product Backlog is updated as and when we get more information. So how the Release Planning can be done in a scenario where the Scope is not fixed?

First let's discuss what Release Planning is in Scrum. Scrum Release Plan is a high level plan for multiple Sprints. It serves as a guideline that reflects how many features will be developed and when those features will be developed. It also serves as a baseline to monitor the progress of the project. Think of it as a roadmap guiding you towards your final destination; what exits you will take or what actions you will take while driving will be decided en route.

In Scrum, before we start Release Planning, we need to have the following items ready.

1. Prioritized and Estimated Product Backlog.
2. Estimated Velocity of the Scrum Team - Total number of Story Points done per Sprint.

Product Backlog: Product Backlog is the list of items/features the Product Owner wants the development team to deliver at the end of the Project. Before the start of the first release, the Product Backlog should be ready. The Product Owner and the Team work together on Product Backlog Refinement. This process could take a few days or weeks. This process may involve workshops, detailed requirement analysis and estimation of all the items identified for the release. 

Estimated Velocity of Scrum Team: 
There are two methods the Velocity can be calculated.

1. Velocity based on Historical Data
2. Velocity Estimation with no Historical Data

Velocity based on Historical Data:
The Following graph represents the historical data of multiple Sprints. Based on this data we get Avg. Velocity (Vavg), Maximum Velocity (Vmax) and Minimum Velocity (Vmin) of a Team. 

Velocity Estimation with no Historical Data:
When there is no historical data then the Velocity can be calculated by using the following method.

Based on the team size and availability, calculate the capacity of team. (e.g. 300 Hours)

1. Select high priority user story from the product backlog
2. Breakdown the user story into tasks.
3. Estimate the tasks in terms of hours.
4. Add the hours of all the tasks of user story.
5. Now check if there is more capacity for a Sprint. 
6. If yes, then repeat the same exercise for the next user stories till you are full with your team’s capacity.
7. Add the total Story Points of User Stories selected for this Sprint.
8. This will give you the velocity for the first Sprint.

Once you have your prioritized Product Backlog and an estimated Velocity, you can start working on release planning.

Release Planning:

As mentioned above, in a traditional software development model Scope, Time and Cost are fixed whereas in Scrum, Scope is evolving. So there are two ways Releases can be planned.

1. Feature Driven Release Planning (Fixed Scope)
2. Date Driven Release Planning

Feature Driven Release Planning:

1. In Feature Driven Release Planning, the features are fixed for the release. 
2. Calculate the total Story Points of the features identified for the release.
3. Add up the Story Points of all the features and divide the sum of story points by expected Velocity.
4. This will give you the number of Sprints needed to complete the required functionality.
5. Based on the Sprint numbers you can arrive at the release date.
6. As Velocity of Team changes from Vmin to Vmax, the number of Sprints needed to complete required functionality as well as release date also changes. 

Date Driven Release Planning:
In the Date Driven Release Planning, Release Date is fixed and number of features delivered by that date can be estimated based on the Team's Velocity.

1. Calculate the number of Sprints for the period of given Release Date.
2. Calculate the estimated Velocity of your team by one of the methods mentioned above.
3. Multiply the Velocity by the number of Sprints for the given Release Date.
4. It will give you the total number of Story Points that can be completed within the given timeline. 
5. As the Velocity of the team changes from Vmin to Vmax, the total Story Points delivered changes.

The final step of Release Planning is drawing a Release Burndown Chart. Based on the Story Points, Velocity and Planned Sprints, Release Burndown Chart is developed. The progress of the project can be tracked with the help of Release Burndown Chart.