What is Scrum Methodology, Everything You Need To Know

WHAT IS SCRUM METHODOLOGY?

Many of my readers keep asking me “What is Scrum Methodology”?  I am going to present a long article describing everything. This article is based on the ScrumGuide.

Scrum is defined as a framework where people can address complex adaptive problems, while also being productive and creative in delivering end products of the highest value.

Scrum also embodies various elements including being light in weight and easy to understand. However, it is noted that it is challenging to master.

A Deeper Look at Scrum Methodology

As has been aforementioned, Scrum is a process framework, and it has been used since the early 1990s. Scrum is used for the management of complex product development, and various processes and techniques go into ensuring this happens.

When you are seeking to improve your management and development practices, Scrum can help clarify the relative efficacy of your product management.

The framework is made up of Scrum Teams who carry out a range of roles, have different artefacts and events and follow a range of rules. Every part of the framework has a purpose that works towards the success of Scrum.

This article explains everything that you need to know about Scrum including the rules and relationships that are involved. Furthermore, there are tactics discussed that reveal the different ways that the Scrum Framework can be used.

Understanding Scrum: Scrum Theory

To understand Scrum, it is important to look at it from its fundamental basics. Scrum has been founded on empirical process control theory which is also known as empiricism. The assertion of this is that knowledge is made up of decision making as well as the experience of known factors.

Therefore, Scrum looks at how to optimise predictability as well as control risk using an Iterative and Incremental approach. For this to occur, there are three pillars required for implementation. These are Transparency, Inspection and Adaptation.

Transparency

There are parts of this process that need to be visible for those who are responsible for the outcome. This requires standard definitions of all aspects to ensure that there is a common understanding of all observations. Consider these examples: –

• All participants referring to the process need to use a common language
• Those carrying out the work, as well as those accepting the result need to have a standard definition of “Done”.

Inspection

Those who use Scrum need to periodically inspect Scrum artefacts and progress when moving towards a Sprint Goal. This ensures that they detect undesirable variances in time. Inspections need to be carried out once in a while so as not to interrupt the work being done.

Skilled inspectors ensure that any inspections are well done and highly beneficial.

Adaptation

Following an inspection, it may be revealed that one or more aspects inside of the process deviate outside acceptable limits. This means that the final product would not be acceptable, and an adjustment should be done on the process or the material that is being used.

The sooner this happens, the better, to bring down the possibility of even more deviation.

Scrum Team

Three members make up the basic Scrum Team, and these are the Product Owner, the Development Team and the ScrumMaster. These teams are expected to be self-organizing and cross-functional.

When they are self-organizing, they can choose the best approach to get the work done and do not count on getting direction from people who are outside the team.

As cross-functional teams, they have all the competencies to accomplish the work at hand, without having to depend on others outside the team. The team is meant to optimise flexibility, creativity and productivity.

Scrum Teams deliver products iteratively and Incrementally, making the most of the opportunities for feedback. Incremental deliveries of “Done” product ensure a possibly useful version of the working product is always available.

If you are interested in having a great team kick off take a look into these two articles: “How To RampUp A Great Agile Team” and “How To Have A Team Kick Off Meeting“.

The Product Owner

When it comes to maximising the value of the product and the work of the Development Team, it is the Product Owner that is responsible. This varies based on the Scrum Teams and the individuals within the team.

The Product Owner has the sole responsibility of managing the Product Backlog. This management includes:

• Clearly expressing Product backlog items
• Ordering items in the Product Backlog to achieve the missions and goals
• Optimise the value of the work the Development Team perform
• Ensure that the Product Backlog is visible, transparent and clear to all.

This reveals what the Scrum Team shall be working on next and will ensure that the Development Team fully understand the items in the Product Backlog to the required level. Even though the Product Owner may delegate this work to their Development Team, they are accountable for the results.

The Product Owner is an individual and not a committee. If there is a committee in place, they may represent their desires in the Product backlog. Those who want to make any adjustments to it need to address the Product Owner.

To ensure that the Product Owner succeeds, everyone in the organisation needs to respect his or her decisions which are visible in the content and ordering of the Product Backlog.

There is no one able to tell the Development Team to work using alternate requirements, and the Development Team are also limited in action on instructions from someone else.

The Development Team

This is a team that is made up of professionals who work to deliver a potentially releasable Increment of “Done” product at the end of each Sprint. It is only the members of this team that can create the Increment.

The organisation ensures the Development Team are empowered to organise and manage their work. The synergy that occurs, as a result, will optimise the efficiency and effectiveness of the Development Team. These teams have the following characteristics:

• They are self-organizing. They do not receive instructions or advice from anyone on how to turn Product Backlog into Increments of potentially releasable functionality.
• They are cross functional and have all the skills required to create a product Increment.
• Scrum does not recognise any titles for the Development Team. Everyone is a developer no matter what work they are performing. This applies without exception.
• Within the Development Team, the Scrum recognises that there are no sub-teams. This is noted even when there are multiple domains that have to addressed, such as business analysis or testing. This applies without exception.
• Every member of the Development Team may have a special skill or focus area, but when it comes to being accountable, the team as a whole is considered.

The Development Team is made up of several people, normally three being the optimum number. This ensures that they remain nimble are still large enough to finish all the work that needs to be done within a Sprint.

If the team has less than three members, the interaction may be reduced meaning that the results will have smaller productivity gains.

Furthermore, the small Development Teams may have constraints in their skills during Sprint, meaning that they may not be able to deliver a potentially releasable Increment.

Large teams, such as those with more than nine members need much more coordination. They end up generating too much complexity for an empirical process to be managed.

When counting the Development Team, the Product Owner and ScrumMaster are not counted unless they are also executing the work of the Sprint Backlog.

The Scrum Master

The ScrumMaster has the responsibility of making sure Scrum has been understood and enacted. They work with the Scrum Team so that they can adhere to the Scrum theory, practices and rules.

The ScrumMaster is essentially the servant-leader for the Scrum Team. If you are in the situation in that you are the ScrumMaster for two teams take a look into: “Your Most Burning Questions About Leading 2 Teams as a ScrumMaster“.

The ScrumMaster helps people who are not in the Scrum Team to understand which of their interactions with the Scrum Team are helpful and which are not.

Understanding the Scrum Master Service

There are three groups that the ScrumMaster Service and these include:

Scrum Master Service to the Product Owner

This is done in numerous ways including:

• Finding techniques for effective Product Backlog management
• Assisting the Scrum Team to understand the need for clear and accurate Product backlog items
• Comprehension of product planning within an empirical environment
• Making sure that the Product Owner is aware of the best way to arrange the Product backlog to maximise the value
• Comprehension and practice of agility
• Facilitating Scrum events as requested or needed

Scrum Master Service to the Development Team

Here, the ScrumMaster will help the Development Team in the following ways:

• Coaching the Development Team in self-organization and cross-functionality
• Assisting the Development Team to create high-value products
• Taking out Impediments to the Development Team’s progress
• Facilitate Scrum Events as requested or needed
• Coaching the Development Team in organisational environments where Scrum has not been fully adopted or understood

Scrum Master Service to the Organization

ScrumMasters can serve the organisation in numerous ways such as:

• Leading and coaching the organisation in its Scrum adoption
• Planning Scrum implementation within the organisation
• Help employees and stakeholders understand the enact Scrum and empirical product development
• Cause change that leads to increasing the productivity of the Scrum Team
• Work with other ScrumMasters to elevate effectiveness of Scrum activation within the organisation

Scrum Values

There are several values that the Scrum Team needs to embody and live by. These are courage, commitment, openness, respect and focus. These values are at the root of bringing the Scrum pillars to life, and building trust with all those involved.

The members of the Scrum Team learn and explore the values as they work with Scrum events, roles and artefacts. For Scrum to be successful, the members of the team need to be proficient in living these five values.

This is how they do so:

• They have the courage to do what is right and work on the tough problems
• They commit to achieving the goals of the team
• The stakeholders and the team agree to be open about the work and the challenges of performing the work
• They respect each other and trust that they are independent and capable
• They focus on the work of the Sprint and the goals of the team

Scrum Events: Inspection and Adaptation Events

There are formally prescribed events that are used in Scrum. These will often regulate and minimise the need have meetings that are not designed in Scrum. All of these events are time boxed, meaning that they all have a maximum duration.

The moment an event, such as the Sprint begins, it has a fixed duration that cannot be changed. Once the purpose of the event has been met, any other remaining events can be brought to an end. This makes sure that there is minimal time wasted during the process.

Every event is providing an opportunity to inspect or adapt something and have been designed to enable critical transparency. There are four formal events that Scrum prescribes too. These are:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective 

Understanding the Sprint

The core of the Scrum is a Sprint. This can be defined as a time-box of one month or less when a “Done”, useable and potentially releasable product Increment is created. They normally have consistent durations throughout a development effort.

Sprints should have constant durations throughout the entire effort of development. A new Sprint will only begin once a previous Sprint has been concluded.

Sprints contain and consist of Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospective and the Development Work.

While the Sprint is ongoing, there should be no alterations made that could affect the Sprint Goal, the quality goals do not decrease, and the scope may be clarified and renegotiated as between the Product Owner and the Development Team as there is more learned.

It is safe to consider each Sprint as a month long project that has to accomplish something. For that reason, the Sprint is clearly defined of what is to be built, design, a flexible plan to guide building it, the work and the final product.

Should the horizon of a Sprint be more than one month, then the definition of what is being built may chance, the risk may go up as well as the overall complexity.

Sprints are important as they make sure that work is predictable and can be inspected and adapted when moving towards the Sprint goal. They limit risk, particularly when it comes to cost.

It is possible to cancel a Sprint before the Sprint time-box comes to a close. However, the only person that has the authority to do this is the Product Owner.

This decision may be influenced by others including the stakeholders, the Development Team or the ScrumMaster. A cancellation may come into effect with the Sprint Goal becomes obsolete.

Obsolescence may be caused by chance in direction, market or technology conditions. If the Sprint does not make any more sense, it should be cancelled. However, you will find that cancellation rarely happens as Sprints have such a short duration.

There are steps that need to take place once the Sprint has been cancelled. The completed and “Done” Product Backlog items are first reviewed. Should some of the work from the Sprint be potentially releasable, it will be accepted by the Product Owner.

Those items that are incomplete within the Product backlog are re-estimated and returned to the Product Backlog. Since this type of work can depreciate fast, it needs to be re-estimated frequently.

Cancellations are discouraged as they consume resources. This is because all those who are involved in the Sprint need to regroup and to be on another Sprint planning process to start another Sprint. They cause some trauma to the Scrum Team and are this avoided.

Sprint Planning

Any work that is to be performed in the Sprint is planned at the Sprint Planning. The plan brings together the entire Scrum Team and is created by collaborative work. Sprint planning is time-boxed to a maximum of eight hours for a month long Sprint; here you can find a suggestion on how to run an effective sprint planning.

When the Sprint is shorter, the event also tends to be shorter. It is up to the ScrumMaster to make sure that the event takes place and the attendants understand the reason for the event. The ScrumMaster will then teach the team to stay within the time box.

Planning, answers the question of what can be delivered in the Increment from the upcoming Sprint, and how the work needed to deliver the Increment will be achieved.

What can be delivered from the upcoming Sprint?

During the Sprint Planning period, the Development Team will work to forecast the functionality that is to be developed during the Sprint.

The Product Owner will discuss the objective the Sprint is looking to achieve. Furthermore, the Product backlog items that will help achieve the Sprint Goal. The whole team Scrum Team will work together on understanding the work of the Sprint.

This meeting has a primary input, and that is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint and the previous performance of the Development Team.

The Development Team will select how many items for the Sprint will come from the Product backlog. It is the Development Team that will provide information on what they can accomplish over the Sprint expectations.

Following a forecast on the Product Backlog items, the Development Team will develop the Sprint while the Scrum Team shall craft the Sprint Goal.

The Sprint Goal is the objective that will be met within the Sprint when the Product Backlog has been implemented. It offers guidance to the Development Team on why the Increment is being built.

If you are interested in the topic some time ago Chris wrote a blog post: “Four Reasons Why Agile User Stories Are Not Getting Done“, take a look.

How will the work be achieved?

Once the Sprint Goal has been set and the Product Backlog items are selected for the Sprint, then the Development Team will decide how functionality will be built into a “Done” product Increment during the Sprint. The Product Backlog Items that are chosen for this Sprint, together with the plan to deliver them is known as the Sprint Backlog.

The Development Team will be designing a system to convert the Product Backlog into a working product Increment. Work may vary in regards to the effort needed and the size of the job. During Sprint Planning, the Development Team will forecast what they believe can be achieved in the upcoming Sprint.

By the end of the meeting, the work that has been planned for the first days of the Sprint which is to be done by the Development Team is decomposed into daily (or less) units. Then self-organization takes place to do the work in the Sprint Backlog, both during the Sprint Planning and as required through the duration of the Sprint.

The Product Owner is tasked with helping to clarify the chosen Product Backlog items and then make trade-offs where necessary. Should the Development Team decide that the work is too much or too little, then it may be renegotiated based on the Product Backlog Items.

This is done with the Product Owner. The Development Team is also at liberty to invite others to attend for the sake of domain or technical advice.

At the end of Sprint Planning, then the Development Team should have the capability to explain to the Product Owner and the Scrub Master how work will be done as a self-organizing team to meet the Sprint Goal.

Sprint Goal

This is an objective that has been set for the Sprint which is easily met once the Product Backlog has been implemented. It offers some guidance to the Development Team on the reason that the Increment is being built. It is during the Sprint Planning meeting that the Sprint Goal is created.

It ensures that the Development Team have a level of flexibility regarding the functionality implemented within the Sprint. The Sprint Goal is delivered through the Product Backlog Items and ensures that the Development Team can work together instead of veering into separate initiatives.

The Development Team works with the Sprint Goal in mind all the time, and this affects their functionality and use of technology. When the is a change in expectations, the Development Team and the Product Owner will facilitate collaboration to negotiation the scope of the Sprint Backlog in the Sprint.

Daily Scrum

Each day the Development Team set aside 15 minutes to synchronise their activities and develop a plan for the next 24 hours. This is known as the Daily Scrum. It involves an inspection of the work that has been done since the last Daily Scrum and then taking look at work that needs to be done before the next one.

It is essential that the time and place of the Daily Scrum remain the same each day, as this will bring down any complexity. In the meeting, the Development Team will explore:

• What was done yesterday that helped the team to meet the Sprint Goa
• What was done today to help meet the Sprint Goal
• What impediments may be preventing team´s ability to meet the Sprint Goal

This means that the Daily Scrum is like a tracker for progress inspection of the Sprint Goal. It ensures that work is on track and based on the Sprint Backlog and makes it so much easier to meet the goal.

The Development Team are challenged during the Daily Scrum to work together as a self-organizing team through detailed discussions where they may have to adapt or replay the rest of the Sprint’s work.

It is the ScrumMaster that ensures this meeting takes place each day, though it is conducted by the Development Team. The ScrumMasters ensures that the team keeps time within the 15 minutes, and enforces the rules for participation.

The benefits of the Daily Scrum are numerous including improving communication, cutting down on the need for other meetings, identifying impediments to development, quick decision making and elevating the overall knowledge of the Development Team.

Some time ago I wrote another blog on “How to run an effective DailyScrum” feel free to check it.

Sprint Review

The Sprint Review is carried out once the Sprint has been done. It is meant to inspect the Increment and adapt the Product Backlog if it is necessary. When the Sprint Review is taking place, the Scrum team and stakeholders evaluate what has been done during the Sprint.

The result of their discussion may lead to changes in the Product backlog, as well as a review of what may be optimised to add value. The review is to share information and is not a status meeting. It is solely held to get some feedback as well as ensure that there is collaboration.

It would take place over a four-hour period if the Sprint ran for one month. If the Sprint was shorter, the meeting will be shorter too.

It includes the following elements:

• Attendance from the Scrum Team and stakeholders as invited by the Product Owner
• Product Owner explains the Product Backlog Items which are “Done” and not “Done.”
• Development Team explain what worked during the Sprint and what did not work, and how problems were solved
• Development Team reveals what is “Done” and provide answers about the Increment
• Product Owner discusses status of the Product Backlog and projects possible completion dates
• The whole group collaborates on the next steps so that the Sprint Review provides valuable input to future Sprint Planning
• Review marketplace or possible use of the product, any changes, and the most valuable thing to do next
• Review timeline, budget, capabilities and marketplace for the release of the product

After the Sprint Review, the Product Backlog is often revised, and the probable Product Backlog items for the next Sprint are defined. It may be adjusted overall to meet with new opportunities. 

Sprint Retrospective

This is a chance for the Scrum Team to carry out an inspection of what has been done and develop a plan for improvements with the next Sprint. It happens once the Sprint Review is complete before Sprint Planning begins again. It is a boxed in

It is a time-boxed meeting taking place over three hours, for one-month Sprints. Shorter Sprints lead to shorter meetings. The ScrumMaster will ensure that it takes place and attendants are clear of its purpose. The

The ScrumMaster will participate as a peer team member to provide information on accountability over the Scrum process. The purpose of this meeting is:

• To inspect the last Sprint
• Identify and order major items that worked and what needs to be improved
• Develop a plan to implement improvements to the Scrum Team and the way they work

The ScrumMaster will use this avenue to encourage the Scrum Team to improve within their process framework, development process and practices. This will ensure that the next Sprint is more effective and enjoyable.

Plans are put in place to elevate product quality by adopting a definition of “Done” as appropriate.

Once the Sprint Retrospective is complete, the Scrum Team will have identified what can be improved for the next Sprint. These will be adapted and then inspected by the Scrum Team themselves. It is the Sprint Retrospective that is a formal opportunity to focus on inspection and adaptation.

If you are interested in this topic you can check my other article: “The Agile Retrospectives Guide That Will Make You A Fantastic Facilitator“. My friend Marc Loeffler wrote an article: “The most 5 asked questions about Agile Retrospectives“. And of course, if you are looking for new ideas for your Sprint Retrospective take a look into: “Agile Retrospectives Ideas“.

Scrum Artifacts

These represent the work or value to provide transparency as well as opportunities for inspection and adaptation. They are defined as being specifically designed to maximise transparency of key information so that all involved have the same understanding of the artefact.

Product Backlog

This is referred to as an ordered list of all the things that are required of the product. It has all the requirements for any amendments that need to be made to a product; it is the Product Owner that is responsible for it.

It is a work in progress, and never really has a final version. It lays down the requirements and continues to evolve as the product evolves. It changes based on what makes the product more appropriate, useful and competitive and will exist as long as there is a product.

It has a list of all the features, requirements, functions, enhancements and fixes that make up the changes to be made to a product in the future released. The items within the Product Backlog have a description, order, estimate and value.

The more that the product is used, and gets value, the more feedback can be expected from the marketplace. This will result in the growth of the Product Backlog as the requirements evolve. It can also change based on the business requirements, conditions in the market and technology.

Where there are multiple Scrum Teams, there may need to work together on one product. In this case, only one Product Backlog will be used to describe the product. To refine the Product Backlog, detail, estimates and the order of items may be amended.

This is done with the Product Owner and the Development Team working in collaboration. While it is being refined, then the items left within it are also reviewed and revised. It is the Scrum Team that will decide how the refinement will be done so as not to take more than 10% capacity from the Development Team.

The Product Owner has the discretion of updating the Product Backlog Items at any time.

There are higher ordered Product Backlog items and lower ordered ones, with the higher ordered ones being cleared and more detailed. It is the higher ones that can reasonably be “Done” by the Development Team, and they are then deemed “Ready” for selection in Sprint Planning.

The Development Team is responsible for all estimates as they are the people who will perform the work. 

Monitoring Progress Toward a Goal

It is possible to calculate the amount of work needed to reach a goal at any time. During the Sprint Review, the Product Owner will track how much work is yet to be done. A comparison is done of the work that has been left over from previous Sprint Reviews and the progress required to complete the current Sprint in the time that has been set. This information is then shared with all the stakeholders that are involved.

To forecast progress, cumulative flows, burn downs and burn-ups are used. Where there is a complex environment, the final result may be unknown so only what has happened in the past will be referred for forward-looking decision making.

Sprint Backlog

The Product Backlog items that have been selected for the Sprint are known as the Sprint Backlog.  They also include the plan to deliver the Product Increment and realise the Sprint Goal.

Fundamentally, the Sprint Backlog is a forecast from the Development Team that looks at how functional each Increment will be, as well we the work required to deliver the functionality into a “Done” Increment.

Sprint Backlog ensure that all the work by the Development Team is visible and can identify to meet the Sprint Goal. The Sprint Backlog essentially is a plan that has the detail required for changes in progress to be understood in the Daily Scrum.

The Development Team can modify the Spirit Backlog through the entire Sprint and then emerge during the Sprint as the Development Team works through the plan. This is because more is learnt about the work necessary to achieve the Sprint Goal.

If there is the need for new work to be done, it is added to the Sprint Backlog by the Development Team. As it is being completed, the estimated remain work is updated. Along the way, any elements of the plan that are not necessary are removed.

It is only the Development Team that can change the Sprint Backlog in the course of a Sprint. The Sprint Backlog is like a visible blueprint for the Development Team and it belongs solely to the Development Team. 

Monitoring Sprint Progress

During the Sprint, the Sprint Backlog can be summed up at any point. It is up to the Development Team to track the total work left for each Daily Scrum to project the possibility of meeting the Sprint Goal. Tracking makes it possible for the Development Team to manage progress.

Increment

The total work left within the Sprint Backlog can be summed up at the time. The Increment is the sum of these as well as the value of any other Increments from previous Sprints.

The final increment at the end of the Sprint should be “Done” meaning that it is in a useable condition and meets the definition that has been set by the Scrum Team.

The useable condition is necessary, whether or not the Product Owner chooses to release it.

Artifact Transparency

For Scrum to be what it is, transparency is essential. This is the basis for decisions that are made to optimise value as well as control risk. The extent of transparency completion determines whether or not decisions are sound. If the artefacts are not completely transparent, then the decisions are flawed and their value will come down. Furthermore, the risk will go up.

The ScrumMaster needs to work with all involved parties including the Product Owner and Development Team to ensure that the artefacts are completely transparent. In the case that there is incomplete transparency, there are practices for coping in place.

The ScrumMaster needs to help all apply the most appropriate practices where the transparency is not complete. Incomplete transparency can be detected by the ScrumMaster when the artefacts are inspected, patterns are sensed and all information is carefully observed.

From this, differences can be detected between the real results and those that were expected. The ScrumMaster needs to work with the Scrum Team as well as the organisation to elevate the transparency of the artefacts. This is done by learning, convincing and change and requires a path to get it right.

Definition of “Done”

The term “Done” has appeared several times throughout this text. When a Product backlog item or an Increment is said to be “Done”, it is essential for all involved to understand the meaning.

It relates directly to work being complete and makes sure that there is transparency. For the Scrum Team, “Done: means that the work done is complete on the product Increment. Some time ago I wrote an example of a “Definition of Done Checklist“.

It is this definition that will offer guidance to the Development Team in the number of Product Backlog items that should be selected during the Sprint Planning process. The reason each Sprint exists is to deliver Increments of potentially releasable functionality that fit within the definition of “Done” from the Scrum Team.

With each Sprint, a Development Team should deliver an Increment of product functionality. It is useable and a Product Owner may decide to release it immediately.  In the event that the definition of “Done” for an Increment is a part of the conventions, standards or guidelines of the development organisation, then all the Scrum Teams need to follow it as a minimum.

In the event that the definition of “Done” is not a convention of the development organisation, then the Development Team of the Scrum Team are tasked with coming up with a definition of “Done” that is in line with the product.

Where there are numerous Scrum Teams working on the product release, the Development Teams on all of them need to mutually defined “Done”.

Every Increment is additive to all the previous Increments and is tested thoroughly. This ensures that they are all working together.

As Scrum Teams mature, then their definitions of “Done” will also expand to include more clarified criteria, here I present some suggestions how you can start with this approach. Every system and product need a definition of “Done” that is the standard applied to the work done on it.

I think this summarises pretty much “What Is Scrum Methodology”. Feel free to leave some comments below.

We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting

Rate this post: