Scrum is the implementation of the Agile Framework that helps us to implement complex projects. Scrum is not only limited to the software development lifecycle, but can also be used for any complex time-scoped works. Scrum is already 20+ years old. It was first presented by Ken Schwaber and Jeff Sutherland at the OOPSLA conference, held in 1995. They presented their learning which they had gained over the few years of implementation of the agile framework in projectssuch as Scrum.
![image]()
Image Source - Setandbma
As per the official Scrum Guide, maintained by Ken Schwaber and Jeff Sutherland, Scrum can be defined as
"A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."
Scrum is:
- Lightweight
- Simple to understand
- Difficult to master
Pillars of Scrum
The base of Scrum is Empiricism, which states that knowledge comes from experience and we should make decisions from what is known. There are the three pillars that hold Scrum together.
- Transparency
It implies that a consensus on the definition of Done is reached by those who work on the deliverable and those who accept the deliverable. In addition to it, the process and progress should be visible to the people involved in Scrum.
- Inspection
People who are involved in Scrum should frequently visit Scrum artifacts in order to make sure that they are on their path to the Sprint Goal. The inspection interval should neither be too short so that it gets in the way of the work, nor too large so that the variations are determined very late in the life cycle.
- Adaptation
Once the inspection finds any deviation from the definition of Done or user acceptance causes the deliverable to be unacceptable, the development tasks or process should be adjusted towards Sprint Goal.
![scrum]()
Image Source - Scrumup.com
Scrum in a picture
The Scrum team roles, events and artifacts, which form the building block of Scrum can be summed up as:
![Scrum]()
Image Source - Jordanjob
Let’s have a dive into each of them.
Scrum Team
Scrum team consists of the product owner, Scrum master and the development team. The Scrum team as a whole is responsible for delivering incremental versions of a shippable product at the end of each sprint. A definition of Done is agreed upon at the beginning of the sprint. Throughout the sprint, the Scrum team inspects and adapts to the changes so that a MVP (Minimum Viable Product) is available at the end of the sprint.
![Scrum]()
Image Source - Create-hub
- Product Owner
Product owner is always a single person. S/he is responsible to maximize the product value. In order to do this, the product owner coordinates with the Scrum team and the development team. Product owner is solely responsible to maintain the product backlog, which is a collection of user stories, that will be taken up for an implementation in the Sprint. Product owner coordinates with the Scrum master to identify the top priority items, that would result in an MVP. Product owner works with the development team to ensure that the Product backlog items are understood to the finest level.
- Scrum Master
Scrum Master is basically the master of Scrum. He ensures that Scrum is understood and enacted in the project development. He is responsible to identify what kind of external interactions are required with the development team, and which will benefit their work and which won’t. He also ensures that daily stand up meetings and other Scrum events are facilitated as required. In case any impediments are hampering the progress of the development team, he makes sure that they are resolved in a timely manner.
- Development Team
They are considered to be a cross functional and self-organizing unit, which will adapt to the changes without any external help. Development team is responsible for the creation of the increment at the end of the sprint, which will be in accordance with the definition of Done.
Scrum Artifacts
Scrum artifacts represent the work that has been/has to be done. They provide a transparent view of what has been done and what is required to be done. Scrum artifacts provide an opportunity to the team to inspect and adapt.
![Scrum]()
Image Source - Coryfoy
- Product Backlog
It contains a prioritized list of the functionalities/implementations/bugs/features that will be required in the product. It serves as the primary go to document for any task that has to be taken up for sprint planning. Product owner is solely responsible to maintain the product backlog. However, he/she can take the help of Scrum master, to order the items as per priority, so that a MVP (Minimum Viable Product) is produced at the end of each sprint. A product back log is never complete. It exists as long as the product exists and evolves with the product, that results in its refinement. As per the feedback session at the end of the sprint, new tasks can be added to the product backlog.
- Sprint Backlog
It represents the subset of items in the product backlog, selected for the implementation in a particular sprint. Creation of the sprint back log happens during the sprint planning session. The development team refines the stories in the sprint backlog to the finest level so that even a slight deviation can be understood during the daily Scrum meeting. The development team is responsible to maintain the Sprint Backlog. By looking at the Sprint Backlog, the Scrum master will be able to identify what has been done so far in the sprint and what remains to be completed in the sprint; thereby helping in tracking sprint progress.
- Product Increment
It is a working subset of the actual product that evolves at the end of the sprint. It should match the definition of Done, agreed upon by the Scrum Team during the sprint planning session; which happens prior to the beginning of the sprint. It should be in a shippable state and the decision to either release it or not is taken by the product owner.
- Burn down Charts
They are used to track the sprint, where the work left to do is plotted against time. Work left is plotted against the vertical axis and time along the horizontal axis. By creating the burn down chart, the Scrum master gets an idea when all the work will be done.
![sprint]()
Image Source - Scrum-Institute
Scrum Events
Scrum events are facilitated by the Scrum master so as to provide an opportunity for inspection and adaptation. Five time boxed events are formally defined by Scrum. Each event has a maximum limit and has to be adhered to.
![Scrum Events]()
Image Source - ScrumBasics
- Sprint
It forms the corner stone of Scrum. Scrum is split into sprints, which is usually time boxed to one month or less, during which a potential shippable product will be created. Once a sprint is completed, the next will start the very next day. Sprint consists of sprint planning, daily Scrum, work done by development team, sprint review and sprint retrospective.
- Sprint Planning
What has to be done in a sprint is defined in the sprint planning. Sprint Planning is also a time boxed event; limited to 8 hours for a one month sprint. If the sprint is shortened, the planning session will be shortened accordingly. Sprint Planning usually takes place in two sessions.
- Session 1
What can be done in this Sprint? The product owner discusses the priority items from the product backlog; that has to be part of the sprint. The development team is based on its current capacity and the past performance forecasts; what it can achieve from the items selected by the product owner.
- Session 2
How to achieve the task? The development team now crafts a high level plan on how to achieve the tasks, by refining the product back log items into fine tasks. The product backlog items, along with the refined tasks, will make up the sprint backlog, which is the main output of the sprint planning.
- Daily Scrum
Daily Scrum is a 15 minute time boxed event, that helps the Scrum team to synchronize the activities and plan for the next 24 hours. Scrum master facilitates the daily meeting and ensures that it falls within the 15 minute time box. The main discussion would be,
- What did I do yesterday?
- What will I do today?
- Do I have any impediments that hamper the progress towards the sprint goal?
The scrum master is responsible for detecting any sprint goal variations by closely watching the daily status meetings and sprint backlogs. He also has to ensure that the impediments are solved in a timely manner.
- Sprint Review
It is held at the end of the sprint to inspect the increments and check whether it has met the definition of Done, as agreed upon by the Scrum team. Scrum team can demo the work done during the sprint to the stake holders and based on the feedback, the product backlog can be updated to implement the feedback in an upcoming sprint, based on its priority. It is usually a 4 hour time boxed event for a one month sprint.
- Sprint Retrospective
It is an internal meeting, where the Scrum team inspects itself and analyses its past sprint performance. The Scrum team then identifies improvement areas; which will help them to adapt in the coming sprint. Some of the major discussion points relate to the process adherence, people relations and external interactions. This is ideally a three hour time boxed event for a one month sprint.
Scrum Lifecycle
![Lifecycle]()
Image Source - Scrum Alliance
- Product backlog is created with the high level user stories that need to be implemented in the sprints.
- Sprint planning takes place by taking a subset of the user stories from the product backlog, resulting in the sprint backlog.
- Once the sprint backlog is ready, the sprint runs for 2-4 weeks and depends on the agreed duration.
- Throughout the sprint, daily Scrum happens for 15 minute every day to make sure that everything is transparent and impediments are not present.
- Once the sprint is completed; a shippable product increment is evolved.
- Sprint review is held to demo the increment to the stake holders and is based on the feedback, the product backlog is updated.
- Sprint retrospective is held to identify the improvements within the Scrum team that will help to adapt and enhance productivity.
Thus, we have seen the basic building blocks of Scrum and how they are used to implement a project.