What is Scrum? – Principles, Events, Benefits, and Accountability

What is Scrum?

A scrum is a lightweight framework to solve complex problems through adaptive solutions 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.

The Scrum framework emphasizes teamwork, accountability, and iterative progress toward 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 (accountability, to be more precise, and 3 artifacts. Yes, scrum only has these 11 elements and nothing more. Oh, wait, there are four 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.

Agile Software development using Scrum somewhere refers to New New Product Development Game published on the Harward Business Review website. Scrum in the context of product development was first mentioned in this paper.

It talks about a similar approach to Rugby where everyone plays a role in Scrum formation. Scrum is about accountability over responsibility and here are 3 accountabilities in Scrum:

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.

Note: The scrum master's responsibilities may vary based on organization culture, context, and industry but accountability usually remains the same. It leads the organization in successful Scrum adoption. It also helps to increase the team's productivity by working efficiently without wasting resources. Does Scrum Master plan Scrum implementations within the organization?

Developers

An incremental release of the final product is created and tested by members of the Scrum team. Developers must know agile and Scrum development practices to improve innovation rate and time to market.

Industry associations and other organizations provide training and certification for these accountabilities to Scrum Masters, Product Owners, and Developers. Some examples of these include the following:

• Scrum.org, which offers Professional Scrum Master Training;
• the Scrum Alliance, which offers the Certified ScrumMaster certification;

What is Scrum Master?

Scrum Master, known as a “Servant Leader,” ensures the team is not violating any Agile & Scrum principles and values promised. A coach, mentor, 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 has no 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, 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, the accountabilities within the Scrum framework, and who is known as Scrum Master, let us elucidate the functioning of Scrum in a detailed manner.

Scrum Events

There are five explicit events in Scrum and one implicit event. Below is a short description of these events. Explicit because it clearly defines 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.

Scrum Team should 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 and so is changing duration but must consider the impact on productivity when changing team members or duration.

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 defined as part of DONE, but scope may be clarified or re-negotiated between the product owner and developers.

Sprint duration varies from team to team, and duration is decided based on 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 such as risk, uncertainty, and amount of assumptions. Factors outside Scrum Team controls can such as cultural barriers and regulatory issues also get considered.

2. Sprint Planning:

The developers prepare 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 monthly 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 two weeks sprint can have 6 hours of sprint planning if needed.

If the Team refines the product backlog continuously for future sprints and can reduce ambiguity in requirements, then sprint planning may take lesser time.

During sprint planning, the team picks up PBIs based on team capacity or velocity and 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 for creating a Sprint Goal.

The Sprint Goal, Forecasted PBIs (many call them user stories)  along with a detailed plan called Sprint Backlog. The team discusses the approach and design to complete PBIs 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. Remember the Sprint Backlog is a plan for Sprint managed by Developers.

A team may also choose some metrics, such as sprint burndown, to help them keep track of team progress besides the scrum board (Sprint backlog). 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 developers) and sometimes SMEs (subject matters expert) if needed. Sprint planning becomes very cumbersome if more than one Scrum 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 had seen teams working fine even when 4-5 teams were working on the same product.

This framework makes more sense when you have more than 40-50 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 developers 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 same place to reduce complexity and confusion. Daily Scrum also is known as a stand-up meeting in many organizations.

During Daily Scrum, every developer shares:-

• Progress made towards the Sprint Goal?
• What planning to do in the next 24 hours to meet the Sprint Goal?
• Any impediments that preventing to meet the Sprint Goal?

The Scrum Master ensures that the Developers have the Daily Scrum. Still, the responsibility to conduct it belongs to the Developers and Scrum Master teaches them to complete it within a 15-minute time-box.

Who attends it? Only developers are 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.

Three things happen during the sprint review event.

• Report – The product owner explains the sprint goal, what is done, and what is not done.
• Demo – Developers demonstrate the product increment, answer questions about the increment, and stakeholders give feedback.
• Forecast – The team along with stakeholders discuss possible paths for the future based on progress made. The Product Owner discusses the product backlog as of the date and 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, salespeople, etc.)

This is not an event for the PO to accept or reject the work done by developers.

PO inspects 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 multiple teams are 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 developers but also for the scrum master and product owner.

This a time-box event and 3 hours for a monthly sprint. Scrum master also participates as a team member to inspect and adapt the Scrum process.

Scrum Masters may facilitate the retrospective meeting if needed or requested.

The scrum team cheers for success, brainstorms for failure, and creates an improvement plan. To make it more fruitful, the team brainstorms collects data, generates insight, and comes up with an improvement plan for upcoming sprints.

Who attends it? Scrum Team. You heard it correctly - the product owner also attended. You can have separate retrospectives if there are multiple teams, and combined quarterly retrospectives if needed. It depends on the team and the coordination between teams.

Product Backlog Refinement

NOT - This is not an EVENT but ongoing activity to add details to your product backlog.

This is a meeting to perform the below activities attended by the Scrum Team, the product owner, and the Scrum master).

• Understand new PBI – PO explains newly added product backlog items and the team asks questions if they need more clarification.
• Split PBI – The team splits PBIs 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. Must remember, estimates are provided by the people who do the work.
• Ordering PBIs – The product owner orders PBIs with a consultation with developers and stakeholders. 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.

Top 6 Key Scrum Benefits in Project Management

• 1Quality products. Feedback and continuous improvement are built into the Sprint retrospective of the Scrum framework. Therefore, high-quality products are delivered by scrum teams using the scrum framework.
• 2Teamwork. 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.
• 3Flexibility. 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.
• 4Reduced 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.
• 5Decreased time to market. Using well-defined sprints, Scrum releases products and their features in shorter increments. At every sprint, releasable and useful features are added.
• 6Higher 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.