What is Scrum?

A scrum is a lightweight software development framework but how much light?

I often see people add too many things and make it a monster. I usually ask participants in my Scrum Developer workshop to write down all those keywords, elements, and buzzwords that come to mind or you have heard so far. What they write is always mind-blowing.

Who is teaching/promoting those keywords?

They start writing user stories, planning poker, story points, agile estimation, release train, epic, burndown, release planning, DevOps, the definition of ready and agile coaching, etc.

All these are part of Scrum? Seriously? These may be helpful for you but not part of the Scrum framework.

Scrum Framework

The Scrum methodology emphasizes teamwork, accountability, and iterative progress towards a defined goal. As a starting point, the framework begins with what is visible or known. Then, track your progress and make any necessary adjustments.

The scrum framework consists of 5 events, 3 roles, and 3 artifacts. Yes, scrum only has these 11 elements and nothing more. Oh, wait there are 2 more implicit elements. Definition of Done and Product Backlog Refinement. So all the above is not needed if not part of Scrum? It may or may not and depends on the team. If those are helping you then continue but be clear that those are not part of the scrum. I will suggest referring to the scrum guide for further clarification.

Software development using Scrum is often part of Agile processes. Everyone plays a role in this rugby formation. The following Scrum roles are involved in software development:

Product Owner

  • Helping find techniques for effective Product Goal definition and Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Helping establish empirical product planning for a complex environment; and,
  • Facilitating stakeholder collaboration as requested or needed.

Scrum Master

  • Coaching the team members in self-management and cross-functionality;
  • Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
  • Causing the removal of impediments to the Scrum Team’s progress; and,
  • Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.


An incremental release of the final product is created and tested by members of the Scrum development team. Agile and Scrum development practices must be known by developers.

Industry associations and other organizations provide training and certification for these key roles. Some examples of these include the following:

Scrumstudy.com, which offers the Scrum Master Certified certification.


  • Leading, trained, and coached the organization in its Scrum adoption;
  • Planning and advising Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
  • Removing barriers between stakeholders and Scrum Teams.

The scrum master roles in these organizations vary. It leads the organization in successful Scrum adoption. It also helps to increase the productivity of the team by working efficiently without wasting resources. Does Scrum Master plan Scrum implementations within the organization.

What is Scrum Master?

Scrum Master known as a “Servant Leader” is someone who ensures the team is not violating any Agile & Scrum principles and values that they promised. A coach, motivator, and leader for an Agile team, Scrum Master is the man behind the show. This means that the Scrum Master is not involved in carrying out product ideation. Scrum Master ensures Scrum is understood by everyone and followed in its entirety. It is a serious job that is deeply rooted in leadership.

Scrum Master is responsible for smoothing the functioning of the process. They work by taking a more holistic approach by rendering services more efficiently while promoting a sense of community.

It is also the most underrated role since Scrum Master’s unlike any other role does not produce any tangible output. The Scrum Master does not have the full authority to make strategic product decisions. However, he or she is accountable for the Scrum process and the effectiveness of the scrum team. Any decisions on the scope of the work are the responsibility of the product owner and not the scrum master. Scrum Master works tirelessly to inculcate the values of Scrum within the team and make it self-organizing.

After understanding what exactly scrum is and who is known as scrum master let us elucidate the functioning of ScrumMaster in a detailed manner. However, it has several roles to perform below sharing the most important ones.

Scrum Events

There are five explicit events in Scrum and one implicit event. Below is a short description of these events. Explicit because clearly defined when these events occur and implicit means the team decides when to have that event.

1. Sprint:

This is a time-box of one month or less depending on various factors but mainly the cost of delay and production. Potentially releasable product increment as per DONE gets created within the sprint. Must have a consistent duration of sprints in order to have sustainable peace and also don’t change team members frequently. Changing team members is allowed but must consider the impact on productivity when changing team members.

Sprint contains and consists of all other events so you may call it a container event. During the sprint, no changes are made that can alter the definition of the sprint goal. Quality must be met as agreed and usually defined as part of DONE but scope may be clarified or re-negotiated between the product owner and development team.

Sprint duration varies from team to team and duration gets decided by various factors. The best possible way to decide is to have the right balance between the Cost of Production and the Cost of Delay. Other factors get applied as well based on the domain in which you are operating. Those factors can be known about engineering practices, culture barriers, regulatory issues, etc.

2. Sprint Planning:

The development team prepares a plan during Sprint planning for work that will get done during a sprint. Sprint planning is a time-box event for 8 hours or less for a 30 days sprint. A shorter sprint may have a shorter sprint planning duration. That doesn’t mean a 15 days sprint can’t have more than 4 hours of planning sessions. Even a 2 weeks sprint can have 6 hours of sprint planning if needed.

If the Team refines the product backlog continuously for future sprints and is able to remove ambiguity in requirements then sprint planning may take lesser time.

During sprint planning, the team picks up PBIs based on team capacity or velocity as well as the definition of DONE. Team craft sprint goals and prepare a detailed plan to meet the sprint goal. An Elevator pitch is a very useful tool to create a sprint goal. Forecasted PBIs along with a detailed plan called Sprint Backlog. The team discusses the approach and design to complete PBIs that get reflected as tasks on the sprint backlog. Sprint backlog may or may not have all the tasks to begin development but tasks get further added/removed from team progress.

A team may also choose some metrics such as sprint burndown to help them keep track of team progress besides the scrum board.

A more elaborated definition of DONE and improvement initiatives may have an influence on sprint forecasts during sprint planning.

Who attends this event? Scrum team (product owner, scrum master, and development team) and sometimes SMEs (subject matters expert).

Sprint planning becomes a very cumbersome event if more than one development team works on the same product. That’s where some Scaling Scrum framework helps. LeSS suggests dividing sprint planning into 2 parts whereas Nexus suggests having a separate Nexus Integration Team. I have seen teams working fine even when there were 4-5 teams working on the same product. This framework makes more sense when you have more than 25-30 developers working on the same product but this is my personal opinion.

3. Daily Scrum:

A time-boxed event for 15 minutes occurs every day for the development team to inspect work done from the last Daily Scrum. The development team inspects work and prepares a plan to adapt for the next 24 hours (before the next daily scrum). Daily Scrum takes place at the same time and in the same place to reduce complexity and confusion. Daily Scrum also is known as a stand-up meeting.

Daily Scrum

During Daily Scrum, every development team members explain below:-

  • What have I done yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevented me or the Development Team from meeting the Sprint Goal?

The Scrum Master ensures that the Development Team has the Daily Scrum, but the responsibility to conduct it belongs to the Development Team and Scrum Master teaches them to complete it within a 15-minute time-box.

Who attends it? Only a development team is required. Yes, Scrum Master can attend but not for taking status. Impediments get reported not only in the daily scrum but actually, it gets reported as soon as identified. Every team runs its own daily scrum if multiple teams work on the same product. The team may have open house sessions frequently to coordinate dependencies with other teams.

4. Sprint Review:

Review held at the end of the sprint to inspect product increment and adapt product backlog. A review is a 4-hour time-boxed meeting for a month-long sprint. A shorter sprint usually will have a shorter duration. Scrum master teaches a team to keep this within the agreed time box.

There are three things that happen during the sprint review event.

  • Report – The product owner explains the sprint goal, what is done and what is not done.
  • Demo – Development Team demonstrates the product increment, answers questions about the increment, and stakeholders give feedback.
  • Forecast – The team discusses what to do next, Product Owner discusses the product backlog as of the date and also discusses the projected completion date, budget, and potential capabilities.

Who attends it? Scrum Team (Product Owner, Scrum Master, and Development Team) and Stakeholders (Sponsor, Customer, end-user, and salespeople, etc.)

This is not an event for the PO to accept work done by a team. PO accepts work during development as soon as PBI is done. This is for stakeholders so stakeholders are identified and invited by the product owner.

A team should demonstrate integrated product increments in case there are multiple teams working on the same product.

5. Sprint Retrospective:

I usually prefer to call it a Kaizen session. This is the event that makes Scrum more interesting. A structured retrospective of everything including how well we have delivered, what we missed, what we could have done better, why product backlog items were not well refined etc. Retrospective not only for the development team but also for the scrum master and product owner.

This a time-box event and 3 hours for 30 days sprint. Scrum master not just facilitates but also participates as a team member to review the Scrum process.

The scrum team cheers for success, brainstorm for failure, and create a plan for improvement. The retrospective should not be very serious or very light but must be a fruitful session. To make it more fruitful, the team plays some games, collects data and generates insight and comes up with an improvement plan for upcoming sprints.

Who attends it? Scrum Team and yes you heard it correctly, the product owner also attended.

You can have separate retrospectives if there are multiple teams as well as combined retrospectives. It depends on the team and the coordination between teams.

6. Product Backlog Refinement

This is an event to perform the below activities and is attended by the product owner and development team.

  • Understand new PBI – PO explains newly added product backlog items and the team asks questions if they need more clarification.
  • Split PBI – The team split swPBIs if they feel PBI is big and will not fit in sprint duration. Ideally, one PBI should not be taking more than 20-25% of the sprint duration. There are some techniques to split and the most popular technique is to INVEST (Independent, Negotiable, Valuable, Estimable, Size appropriate, and Testable). I also suggest writing all possible scenarios for PBIs because that helps in splitting. Some teams write use cases and usage scenarios to understand the size of PBI.
  • Estimation – Estimating PBIs based on team consensus so the product owners can forecast. You like to size PBI by using relative estimation or can go for the absolute number using bottom-up estimation or 3 points estimation.
  • Ordering PBIs – The product owner orders PBIs with a consultation with a development team. The team helps the PO to understand the technical dependency of PBI and PO usage of some prioritization techniques such as MOSCOW and KANO model etc.

This becomes massive work when multiple teams work on the same product. Many times product owners take help from business analysts (SMEs) to manage work on the PO side. These business analysts are not PO and not even proxy PO, they are just extra hands for the product owner.

Benefits of Scrum Methodology

Following are some of the core benefits of Scrum:

  • Quality products. Feedback and continuous improvement are built into the Sprint retrospective of the Scrum process. Therefore, high-quality products are delivered by development teams using the methodology.
  • Teamwork. Scrum promotes cohesive software development teams that communicate effectively, meet deadlines, and solve problems together. Each member respects and trusts one another, and understands the value of their time. In this case, limiting the daily Scrum to a strict time frame might be necessary. Hacking sprints are part of some software development processes. It allows developers to work on new concepts, try out new ideas and take ownership of products.
  • Flexibility. As new circumstances arise, Scrum teams must adapt their tools and processes. As development progresses, product definitions may change, and effective teams are able to make those changes within a few iterations. Priorities can be rearranged before products are moved into the sprint through regular product backlog meetings.
  • Reduced Risk. In Scrum, teams are given a chance to mitigate risk early and often through a predictable, sustainable delivery pace and consistent feedback. When an idea doesn’t work, short sprints let teams fail fast, reducing the risk of failure.
  • Decreased time to market. Using well-defined sprints, Scrum releases products and their features in predictable increments. The entire product does not need For features to be released, work needs to be done. At every sprint, shippable features are added. Composed of those shipped features, complex products are complete products.
  • Higher return on investment (ROI). Scrum’s combined benefits lead to a higher ROI. Constant feedback leads to less costly mistakes late in the process and a better product with fewer defects. Decreased time to market and incremental releases bring in revenue faster.
Author's Bio

Naveen is a Lean-Agile Coach, Professional Scrum Trainer (PST) and Internationally acclaimed Speaker in many Conferences and Agile events. He has over 22 years of experience in multiple domains and he is a Certified LeSS Practitioner (Large-Scale Scrum) and one of the early adopters of DevOps practices and teaches DevOps culture around the Globe.