Definition

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Scrum helps organizing teams and get work done more productively with higher quality. Scrum is about the interactions and processes.

Scrum allows teams to choose the amount of work to be done and decide how best to do it. It focuses on prioritizing work based on business value, improving the usefulness of what is delivered. It is designed to adapt to changing requirements during the development process at short and regular intervals.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.

Three factors plays an important role in implementing Scrum:

• Transparency: all aspects of the process must be transparent and visible to all people in the Scrum process. Everyone should have a common understanding of what is going on.
  
• Inspection: Scrum artifact should be inspected frequently during the process to detect any undesirable outcomes in order to take a proper action to avoid them.
  
• Adaptation: if any deviation has been detected during the Scrum process, that results an unacceptable product, the process should be adjusted accordingly to avoid further deviation.
  

Scrum is a simple “inspect and adapt” framework that has three roles, three ceremonies, and three artifacts designed to deliver working software in Sprints, usually 10 to 30 days iterations.

• Roles:
  
  • Product Owner
    
  • Scrum Master
    
  • Development Team
    
• Ceremonies (Scrum Events):
  
  • Sprint Planning
    
  • Sprint Review
    
  • Sprint Retrospective
    
  • Daily Scrum Meeting
    
• Artifacts:
  
  • Product Backlog
    
  • Sprint Backlog
    
  • Burndown Chart
    

Figure 1 – Scrum

Scrum Roles (the Scrum Team)

Scrum Teams are cross-functional and self-organized. The teams themselves will decide how to accomplish their works in the best way, rather than being directed by others outside the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback.

The Scrum Team consists of:

• Product Owner
  
• Scrum Master
  
• Development Team
  

Product Owner

The Product Owner a single person that is responsible for maximizing the value of the product and the work of the Development Team. He is the only person responsible for managing the Product Backlog.

His responsibilities include:

• Responsible for the profitability of the product (ROI).
  
• Defines the product features.
  
• Responsible for product vision.
  
• Defines the project timeline.
  
• Prioritizes features according to the market value.
  
• Clarifies the requirements for the Scrum team.
  
• Approve or disapprove the work results at the end of every product increment.
  
• Adjust the product features and priorities at the beginning of each Sprint.
  

Scrum Master

Scrum master is a person within the Scrum team who has leadership role and facilitates the Scrum processes. She is responsible to ensure that the Scrum processes understood well within the team members and everyone is following the Scrum practices and rules.

Scrum master serves both the Development Team and the Product Owner.

• Helps to manage the Product Backlog.
  
• Helps the team to understand the Product Backlog.
  
• Helps the Product Owner to prioritize the Product Backlog Items.
  
• Coaches the development team throughout the Scrum events and processes.
  
• Helps removing the impediments and obstacles the Development Team face.
  
• Uses tools and technics which helps the Scrum artifacts be visible.
  
• Ensures the cross-functionality and self-organization of the Development Team.
  
• Avoid external distractions affect the Development Team.
  

Note: the Scrum master is not a Project Manager and has no management authority over the team. The Scrum master can be a person from the development team itself.

Development Team

The Development Team does the actual work of delivering a product increment at the end of each Sprint.

The team characteristics are as below:

• It is cross-functional consists of one or more developers, testers, domain experts, functional designers, etc.
  
• It is self-organizing and self-managing and no external authority can affect its processes.
  
• It has leadership role.
  
• The team does not have any sub-teams.
  
• Its size is usually between 5 and 9 people (excluding the Product Owner and Scrum Master unless they involve in the development’s work).
  

Figure 2 – Scrum Roles / Artifacts / Processes

Scrum Events

The Scrum begins when enough of the Product Backlog is defined and prioritized to launch the first Sprint.

All events in Scrum are time-boxed, that is, they have maximum duration. Sprint itself is an event where all other events happened inside it. The events are designed to critical transparency, inspection, and adaption.

The Sprint

The heart of Scrum is a Sprint, a time-box of two to four weeks during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints consists of the following events:

• Sprint Planning
  
• Daily Scrums
  
• Development work
  
• Sprint Review
  
• Sprint Retrospective
  

Changes should be minimized to avoid endangering or reduce the quality of the Sprint goals. Scope of the items in the Sprint can be re-negotiated or clarified with the Product Owner during a Sprint.

Sprints are used to accomplish something. 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 (increment).

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase.

Sprint Cancelation

Sprint can be canceled whenever its goals become obsolete due to company direction changes, market changes, or etc. Only the Product Owner can cancel a Sprint.

When a Sprint has canceled, any completed Product Backlog Items are reviewed and the product owner will be accepting the part of a work which is realizable. Any incomplete items will be re-estimated and put back on the Product Backlog.

Sprint Planning

Sprint Planning Meeting is used to develop a detail plan for the iteration. The Scrum Master leads the meeting. Sprint planning is time-boxed for maximum of eight hours for a one-month Sprint. For shorter Sprints, this event is usually shorter.

• It starts with Product Owner reviewing the vision, the roadmap, the release plan, and the Product Backlog with the Scrum Team.
  
• The Team reviews the estimates for features on the Product Backlog as accurate as possible.
  
• The Team defines the available resources and hours for that Sprint and decides how much work it can successfully take into the Sprint based on that.
  
• The Team pulls the selected Product Backlog Items (PBI) from the Product Backlog to Sprint Backlog. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
  
• The Team breaks down the Sprint PBIs into Sprint tasks. Normally tasks are broken down into pieces that will require less than one day or eight hours of work.
  

When the Sprint Backlog is complete, the total work estimated is compared with original estimates from the Product Backlog. If there is a significant difference, the team negotiates with the Product Owner to get the right amount of work to take into the Sprint. The Development Team may also invite other people to attend in order to provide technical or domain advice.

Daily Scrum Meeting (Standup Meeting)

The Daily Scrum Meeting is 15 minutes time-boxed event for the Development Team to synchronize their activities and clarify the state of the Scrum.

• The Daily Scrum Meeting will be held at the same time and same place every day.
  
• While anyone can attend this meeting, only the team members who have committed to deliver work to the Scrum allowed to speak.
  

The Development Team address the following items in the Daily Scrum Meeting:

• What did I do yesterday?
  
• What will I do today?
  
• What impediments do I have?
  

Any further discussions, clarifications, etc. among the team members whom are interested can be done immediately after the Daily Scrum Meeting ends. The Daily Scrum Meeting should not be exceeded the 15 minutes time-box, standup at the meeting can help keeping it short.

Daily Scrum Meetings improve communication, identify and remove impediments, and increase the knowledge of the team.

Scrum Master needs to know the state of each tasks and any changes need to be done to what has planned in Sprint. Scrum Master needs to identify impediments or dependencies and track them. She needs to help resolving the impediments whether they are related to the Development Team or outside of the team. She also needs to identifies personal problems and conflicts and resolve them.

Backlog Refinement

Backlog Refinement Meeting happens once in a Sprint, normally in the middle, so the team have a chance to refine the Product Backlog Items to be planned for the next Sprint. The Development Team provides estimation on the PBIs and other technical information to help Product Owner to re-prioritize the Items. PBIs will be clarified and might splits into smaller PBIs.

The Backlog Refinement meeting is two-hours time-boxed or less.

Sprint Review

The meeting will be held at the end of the Sprint within the time-box of four hours for one month Sprint. It can be shorter for smaller Sprints. The Development Team presents the works that have been completed during the Sprint to the Product Owner. The meeting should be a live demonstration, not a report. The Product Owner determines which items have been “Done” and might feedback on the work. The Product Owner can invite the stakeholder to the meeting too.

The Product Backlog might be re-adjusted during this meeting based on the Product Owner and stakeholder’s feedbacks and the Goal for the next Sprint can be defined. The Sprint Review helps refining everyone’s understanding of the requirements.

Sprint Retrospective

The Sprint Retrospective will be held immediately after the Sprint Review and before. It gives an opportunity to Scrum Team to inspect itself and plan for improvements to be enacted during the next Sprint. The meeting is three hours tome-boxed for one month sprint. It is shorter for a smaller Sprints. Scrum Maser participates as a team member while leading the meeting.

In the Sprint Retrospective the team inspects how the last Sprint went, defines what went well and potential improvements, and create a plan for improvements to be implemented in the next sprint.

Figure 3 – Sprint Events

Sprint Artifacts

Scrum’s artifacts represents the work being carried out in a Sprint. It provides transparency and opportunity for inspection and adaption. It helps everyone in the Development Team to have the same understanding on what is going on.

Scrum Master will work together with the Product Owner and the Development team to ensure that all the artifacts are transparent and accurate.

Product Backlog

The Product Backlog is the list of requirements, features, functions, enhancements, fixes, and anything else that needed in the product’s future releases. The Product Backlog initiate by the initial known requirements and it will evolve throughout the development in various events such as Backlog Refinement or Sprint Review meetings, or the stakeholder’s feedbacks. The Product Backlog is a live artifact and it never stops changing.

The Product Owner is responsible to create and manage the Product Backlog and defines the priority of the items.

Product Backlog Item (PBI)

Each Item in the Product Backlog is called Product Backlog Item (PBI). A PBI clearly describes a requirement which needs to be done. A PBI has description, complexity, estimation, and other necessary information the Development Team need to know in order to develop it. A BPI is often written in User Story form and it describes what rather than how

When a PBI has revised and the estimation done by the team, it is “Ready” to be selected for any future Sprints. The team will select a list of “Ready” PBIs they can complete in one Sprint, in the Sprint Planning. By selecting a PBI the Development Team “Commit” to complete it in one Sprint. After the Sprint Review the Product Owner will decide which completed BPI is “Done”.

The definition of “Done” should be clearly defined by the Product Owner and the team has common understanding on what it does mean.

Figure 4 – Product Backlog Item (in Visual Studio)

Sprint Backlog

Sprint Backlog is a subset of Product Backlog which has selected for the next product increment. Sprint Backlog includes a list of “Ready” PBIs which the team planned to complete them in one Sprint in the Sprint Planning meeting. Sprit Backlog clearly shows all the works defined by the development team in order to reach the Sprint goal. It is visible to everyone and the status of PBIs will be changed every day after the Daily Scrum Meetings.

A PBI in the Sprint backlog is “Committed” to be completed at the end of the Sprint. The Development Team updates the remaining efforts needed to complete a PBI every day after Daily Scrum Meeting. The Development Team can add or remove works necessary to complete a PBI to the Sprint Backlog. The Development Team will revise each PBI’s complexity during the Sprint Planning.

Only the Development Team can change the Sprint Backlog during a Sprint.

Sprint Task

Each PBI in the Sprint Backlog consists of series of tasks, needed to be performed during a Sprint by different team members, in order to complete it. Each task should be able to be completed in one day or less.

Figure 5 – Sprint Backlog

Sprint Burn-down Chart

Every Sprint Task has an effort estimation which is normally in hours. The remaining effort will be updated every day after the Daily Scrum Meetings. When a task is completed the remaining effort will be zero. The sum of total remaining efforts can be calculated at the end of each Daily Scrum Meeting. If the sum off all estimated effort is zero at the end of Sprint, the Sprint is successful. This cumulative data can be represented in a Burn-down chart which gives a better picture of the Sprint to the Scrum team.

Figure 6 – Burndown Chart