SCRUM Components

04 August 2016

The aim of this article to give a high-level insight into the main components used within the SCRUM methodology/process/management principle.  Before we delve into this, here is a brief description of what the SCRUM is and aims to do:

“SCRUM is a methodology used to manager projects.  SCRUM is primary used within the software development industry, for managing delivery of software projects, however SCRUM is also used across a large number of other industries.  Note, one of the primary aim of SCRUM is to empower and promote self-governing and self-aware teams, which can and do manage the delivery of products.”

Scrum key component image

Key Components

The diagram below shows the key elements of the SCRUM team and methodology.  Please note, there are more and each team may diff a little.  SCRUM actively encourages team to find what best works for them, so each team may have more or less components.


The team is usually made up of 5-6 people. As a combined team they have the knowledge, influence and power to make changes to the product.  The team ideally is a self-empowering and self-aware entity. 

Product Owner

The product owner is the business representative or key stakeholder for the product.  They tend to be the representative from the business and has direct communications with customers.

SCRUM Master

The sole aim of the SCRUM master is to facilitate the agile approach and ensure the team are working as efficiently as possible.


Outside the SCRUM master and product owner the team is made up of developers, QA/testers, UI designers etc.

One important aspect of the SCRUM methodology is that all members are equal and decisions are made as a team.  For example, the team decides on how much works enters the sprint, the team decides on the velocity of the sprint, and ultimately the team is responsible for the complete of the work promised.  This all leads to a mode stable and empowered, happy team.

 The following table gives a breakdown of some of the key responsibilities held by different team members:

Product Owner

Scrum Master

The Team

He defines features of the product.

  He manages the team and look after the team's productivity

 The team is usually about 5-6 members

 Product Owner decides release date and corresponding features  He maintains the block list and removes barriers in the development  It includes developers, designer and sometimes testers, etc.
 They prioritize the features according to the market value and profitability of the product  He/She co-ordinates with all roles and functions  The team organizes and schedule their work on their own
 He is responsible for the profitability of the product  He/She shields team from external interferences  Has right to do everything within the boundaries of the project to meet the sprint goal
 He can accept or reject work item result  Invites to the daily scrum, sprint review and planning meetings  Actively participate in daily ceremonies

2 - SCRUM Artifacts

The SCRUM artifacts are used to help define the workload coming into the team and currently being worked upon the team.  There are many more artifacts, for example, User stories, Release backlog, Burn-up chart etc.  But we will concentrate on the core three:

Product backlog

The product backlog is a collection of user stories which present functionality which is required/wanted by the product team.  Usually the product owner takes responsible for this list.

Sprint Backlog

Sprint backlogs contain a collection of stories which could be included in the current sprint.  Two important points to note about the relationship between the sprint backlog and the inclusion of items into the sprint. 1) The team decides what gets added to the sprint.  The team therefore takes ownership and responsibility of the delivery of those items. 2) Before an item can be removed from the sprint backlog and added to the sprint, the team must ensure they have all the information needed within the backlog.  Usually a team defines a checklist of items which must be present before the item can be added.

Burn-down Chart

The burn-down chart helps the team give visibility of the sprint progress, the burn-down chart will clearly show anyone the current status of the items within the sprint.  The burn-down chart will at a minimum show the number of hours remaining against the number of days in the sprint remaining.  The closer the team gets to the end of the sprint, the lower the number of hours effect should remain – or that is the theory.

3 – SCRUM Ceremonies

Communication is key!  SCRUM relies on all aspects of the team being and working transparently.  With this core ethos in mind, the methodology is structured around a number of key meetings/ceremonies.

Sprint Planning

All sprints begin with planning.   The team needs to identify and commit to which items are going to be delivered as part of the sprint.  The possible items are always taken from the Sprint Backlog.  This is the time where the SCRUM master can shine.  The product owner, identifies aspects they need from a business/customer point of view, the SCRUM team, identify which items they think they can deliver and the SCRUM master accommodates all and ensure the best of both worlds are met.

Daily SCRUM Meeting

Once the team have identified the items they are committed to delivering as part of the sprint.  The team will have a daily stand-up meeting.  The core aim of this meeting is to ensure everyone within the team (and possible observers) full visibility of what they have done, what they are going to day and what is stopping them.  This daily update provides instance feedback to the team and provides.  These meetings are meant to be short and snappy no longer than 3 minutes per person.  Note, observers are there to observe, the SCRUM master must where possible mitigate outside interruptions and distractions to the team.

Sprint Retrospective

Once the sprint is complete and the software has been delivered the retrospective gives the team the opportunity to identify 3 key aspects: 1) What did not go well? 2) What went well? And 3) What we can do different next time.  The aim of this approach is to continually improve the team efficiency.


This is a quick overview of the core components to a SCRUM team, they are by no means a complete list, the more experienced SCRUM readers will see I have missed out burn-up charts, backlog grooming, sprint demo’s etc.   These items will be covered in the SCRUM process article. 

Further reading

-          SCRUM Testing: A Beginner’s Guide (link)

-          A beginner’s guide to SCRUM (link)

-          Wiki: SCRUM (Software development) (link)

 Agile  SCRUM