Scrum is an Agile project management framework that helps teams organize and oversee their work through values, principles, and practices. Scrum encourages teams to learn through experience, self-organize while working on a problem, and reflect on their successes and failures to continuously improve.

Who primarily uses the Scrum framework?

Software development and engineering teams widely use the Scrum methodology to adapt to changing requirements and manage costs. However, devs and engineers are not the only users. Its principles and lessons can be applied to all kinds of teamwork from marketing to IT teams.

People often think Scrum and Agile are the same because Scrum is centered around continuous improvement, a core principle of Agile. However, Scrum is a framework for getting work done, whereas Agile is a philosophy. 

The Agile philosophy centers around continuous incremental improvement through small and frequent releases. You can’t really “go Agile” because it takes dedication from the whole team to change how they think about delivering value to your customers. 

However, you can use a framework like Scrum to help you start thinking that way and practice building Agile principles into your everyday communication and work.

The difference between Agile and Scrum can be found in the Scrum Guide and the Agile Manifesto. The Agile Manifesto outlines four values:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change by following a plan

Scrum is based on empiricism and lean thinking. Empiricism says that knowledge comes from experience and that decisions are made based on what is observed.

Often used in tandem with Kanban boards, lean thinking reduces waste and focuses on essentials. Scrum theory refers to these foundational principles—empiricism, lean thinking, and iterative improvement.

When done correctly, this guides the structure, practices, and continuous improvement of Scrum implementations.

The history of the Scrum framework owes much of its success to the pioneering work of Jeff Sutherland. Alongside Ken Schwaber, Sutherland developed Scrum in the early 1990s to respond to the challenges of managing complex software development projects. 

Sutherland brought a unique perspective to project management that emphasized teamwork, adaptability, and clear communication. His experiences in high-pressure environments shaped Scrum's collaborative and iterative nature, making it a powerful tool for tackling complex problems. 

Today, Sutherland’s influence is evident in how Scrum teams organize their work, deliver value, and continuously improve.

Scrum requires specific roles and components, including a Scrum Master, Product Owner, and the Scrum Team, to deliver value through iterative sprints.

The Scrum framework outlines a set of values, principles, and practices that Scrum teams follow to deliver a product or service. It details the members of a Scrum team and their accountabilities, or Scrum artifacts. 

These artifacts define the product and work to create the product, while Scrum ceremonies guide the Scrum team through work. A Scrum team consists of a small, cross-functional, self-managing unit responsible for delivering a valuable product increment each sprint.

While Scrum is structured, it is not entirely rigid. Its execution can be tailored to the needs of any organization. There are many theories about how Scrum teams must work to be successful. 

However, after more than a decade of helping Agile teams get work done at Atlassian, we’ve learned that clear communication, transparency, and a dedication to continuous improvement should be at the center of whatever framework you choose. 

The rest is up to you.

A Scrum team is a small, nimble team dedicated to delivering committed product increments. It’s typically a lean, tight-knit group of roughly 10 people. 

But it’s often large enough to complete a substantial amount of work within a sprint. Most Scrum teams need three roles: product owner, Scrum master, and the development team.

Product owners are the champions for their product. They are focused on understanding business, customer, and market requirements.

This role prioritizes the work to be done by the engineering team accordingly. Effective product owners:

• Builds and manages the product backlog.

• Uses sprint backlog management by developing, ordering, and transparently managing the product backlog for effective planning and prioritization.

• Partners with the business and the team to ensure everyone understands the work items in the product backlog.

• Gives the team clear guidance on which features to deliver next.

• Decides when to ship the product with a predisposition toward more frequent delivery.

The product owner is not always the product manager. Product owners focus on ensuring the development team delivers the most value to the business. 

The product owner must be an individual. No development team wants mixed guidance from multiple product owners.

Scrum masters are the champions of Scrum within their teams. They coach teams, product owners, and the business on the Scrum process and look for ways to fine-tune their practice. 

A key responsibility of the Scrum master is to enhance the Scrum team's effectiveness by coaching, removing impediments, and facilitating Scrum processes. This helps them improve overall team performance and delivery.

An effective Scrum master deeply understands the team's work and can help the team optimize its transparency and delivery flow.

As the facilitator-in-chief, they schedule the necessary resources (both human and logistical). These resources cover everything from sprint planning, stand-ups, sprint reviews, and sprint retrospectives.

Scrum development teams get s*%& done. They are the champions of sustainable development practices. 

The most effective Scrum teams are tight-knit, co-located, and usually consist of five to seven members. One way to work out the team size is to use the famous ‘two pizza rule’ coined by Amazon CEO Jeff Bezos, which means the team should be small enough to share two pizzas.

Team members should have diverse skill sets and cross-train each other, so that no single person becomes a bottleneck in the delivery of work. Strong Scrum teams are self-organizing and approach their projects with a clear ‘we’ attitude. 

All team members help one another to ensure a successful sprint completion. The Scrum team drives the plan for each sprint. 

They forecast how much work they can complete over the iteration using their historical velocity as a guide. The team uses past performance to inform their capacity and improve the accuracy of their sprint planning. 

Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, making their forecasts increasingly accurate. Based on this evaluation, the team carefully considers what can be delivered in the upcoming sprint.

Scrum artifacts are essential information that the Scrum team uses to help define the product and what work needs to be done to create it. Scrum has three artifacts: a product backlog, a sprint backlog, and an increment with your definition of done (DoD). 

A Scrum team should reflect on these three constants during sprints and throughout their development.

This is the primary list of work that the product owner or product manager needs to do and maintain. This is a dynamic list of features, requirements, enhancements, and fixes that acts as the input for the sprint backlog. 

It is, essentially, the team’s “To Do” list. 

The product backlog is constantly revisited, re-prioritized, and maintained by the Product Owner. As teams learn more or if the market changes, items may no longer be relevant or problems may get solved in other ways. 

Backlog items are prioritized to maximize customer value, ensuring that features delivered directly enhance customer satisfaction and long-term business value.

This is the list of items, user stories, or bug fixes, selected by the development team for implementation in the current sprint cycle. Before each sprint during sprint planning, the team selects items it will work on from the backlog.

A sprint backlog may be flexible and can evolve during a sprint. However, the fundamental sprint goal – what the team wants to achieve from the current sprint – cannot be compromised.

Increment, or commonly known as the sprint goal, is the usable end-product from a sprint. At Atlassian, we typically demonstrate the increment during the end-of-sprint demo, where the team showcases what was completed during the sprint. 

This term is often referred to as the team’s definition of Done, a milestone, the sprint goal, or even a full version or a shipped epic. It just depends on how your team defines Done and how you define your sprint goals.

For example, some teams release something to their customers at the end of every sprint. So their definition of ‘done’ would be shipped. As you can tell, your team can choose to define many variations, even within artifacts. 

That’s why it’s essential to remain open to evolving how you maintain your artifacts. Perhaps your definition of done is causing undue stress on your team, and you need to revisit and choose a new definition.

The Scrum framework encompasses practices, ceremonies, and meetings that Scrum teams conduct on a regular basis. The Agile ceremonies are where we see the most variations for teams. 

We advise using all the ceremonies for two sprints and seeing how it feels. You can then perform a quickreview and see where to make adjustments. Below is a list of all the key ceremonies a Scrum team might partake in:

Sometimes known as backlog grooming, this event is the product owner's responsibility. The product owner’s main job is to drive the product towards its product vision and have a constant pulse on the market and the customer. 

They maintain this list using feedback from users and the development team to help prioritize and keep the list clean and ready for work at any given time.

The entire development team plans the work to be performed (scope) during the current sprint during this meeting. The Scrum master leads this meeting, which is known as the sprint planning event.

During this meeting, the team determines the sprint goal and plans the work to be completed. Specific user stories are then added to the sprint from the product backlog.

These stories always align with the goal and are also agreed upon by the Scrum team to be feasible to implement during the sprint. By the close of the planning meeting, all Scrum team members should have a clear understanding of what will be delivered during the sprint and how the increment will be achieved.

A sprint is the actual time period during which the Scrum team collaborates to complete an increment. These time-boxed iterations are called sprints and typically last from one to four weeks. 

Two weeks is a typical sprint length, though some teams find a week to be easier to scope or a month to deliver a valuable increment. Dave West, from Scrum.org, advises that the more complex the work and the more unknowns, the shorter the sprint should be. 

But it’s up to your team, and you shouldn’t be afraid to change it if it’s not working! During this period, the scope can be renegotiated between the product owner and the development team if necessary. 

This forms the crux of Scrum's empirical nature. All the events from planning to retrospective happen during the sprint. Once a specific time interval for a sprint is established, it has to remain consistent throughout the development period. 

This helps the team learn from past experiences and apply that insight to future sprints.

Daily Scrum or stand-up

This super-short daily meeting happens simultaneously (usually mornings) and is a place to keep it simple. These pivotal, time-boxed meetings are called daily Scrums and are designed to inspect progress towards the Sprint Goal, coordinate team activities, and identify impediments. 

Many teams try to complete the meeting in 15 minutes, but that’s just a guideline. This meeting is also called a ‘daily stand-up,’ emphasizing that it needs to be quick. 

The goal of the daily Scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours. You can use a daily stand up template to help kickstart meetings and get organized faster.

The stand-up is the time to voice any concerns about meeting the sprint goal or blockers. A common way to conduct a stand-up is for every team member to answer three questions in the context of achieving the sprint goal:

• What did I do yesterday?

• What do I plan to do today?

• Are there any obstacles? 

However, we’ve seen the meeting quickly turn into people reading from their calendars from yesterday and the next day. The theory behind the stand-up is that it keeps distracting chatter to a daily meeting so that the team can focus on the work for the rest of the day. 

So if it turns into a daily calendar read-out, don’t be afraid to change it up and get creative.

At the end of the sprint, the team gets together for an informal session to view a demo or inspect the increment. The development team showcases the backlog items that are now Done to stakeholders and teammates for feedback. 

The product owner can decide whether or not to release the increment, although in most cases the increment is released. This review meeting is also when the product owner reworks the product backlog based on the current sprint and can feed into the next sprint planning session.

For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.

The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. 

The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less on what went wrong.

In 2016, five Scrum values were added to The Scrum Guide. These values provide direction toward work, actions, and the behavior of the Scrum team. Effective collaboration, commitment to tasks, and adherence to Scrum principles are essential for achieving the team's success within an Agile environment.

Commitment

Because Scrum teams are small and Agile, each team member plays a significant role in the team's success. Each team member should agree to commit to performing tasks they can complete and not overcommit. 

There should be frequent communication regarding work progress, often in stand-ups.

Courage

Courage for a Scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage and feel safe enough to try new things. 

A Scrum team should also have the courage and feel safe enough to be transparent about roadblocks, project progress, and delays.

Focus

At the heart of the workflow for Scrum teams is the sprint, a focused and specified period where the team completes a set amount of work. The sprint provides structure but also focus to complete the planned amount of work.

Openness

The daily stand-up fosters an openness that allows teams to openly discuss work in progress and blockers. At Atlassian, we often have our Scrum teams address these questions:

• What did I work on yesterday?

• What am I working on today?

• What issues are blocking me?

This helps to highlight progress and identify blockers. Sharing progress also strengthens the team.

Respect

The strength of an Agile team lies in its collaboration and recognizing that each team member contributes to the work in a sprint. They celebrate one another’s accomplishments and respect each other, the product owner, stakeholders, and the Scrum master.

While Scrum is the most widely adopted agile framework, it’s not the only one available. Kanban offers an alternative approach that emphasizes continuous delivery and flow rather than fixed-length iterations.

In Kanban:

• Work items are visualized on a board and managed with work-in-progress (WIP) limits.

• Teams pull in new work only when capacity frees up, creating a steady, continuous flow.

• There are no prescribed roles or ceremonies, making Kanban more flexible and lightweight than Scrum.

When to use Kanban:

• Ideal for teams with a continuous stream of incoming tasks (e.g., support or operations).

• Useful when priorities shift frequently and fixed sprint commitments are hard to maintain.

When to use Scrum:

• Best suited for product or feature development where incremental delivery, structure, and predictability are crucial.

• Works well for teams that benefit from clearly defined roles, ceremonies, and sprint goals.

Hybrid approaches:

Some teams combine elements of both frameworks into what’s often called Scrumban or Kanplan (Kanban with a backlog). This hybrid enables teams to maintain Scrum’s backlog and planning discipline while incorporating Kanban’s flexibility in execution.

The Scrum Alliance is a leading resource for those looking to deepen their understanding of Scrum principles and advance their careers. As a global organization dedicated to promoting the Scrum framework, the Scrum Alliance offers a range of certifications and training programs.

These are designed for Scrum masters, product owners, and other Scrum practitioners. In fact, the Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) certifications are especially popular.

They provide professionals with a solid foundation in Scrum practices and values. Earning these credentials demonstrates a commitment to Agile methodologies and opens doors to new project management and software development opportunities. 

With access to a vibrant community, ongoing education, and industry-recognized certifications, the Scrum Alliance helps individuals and organizations succeed with Scrum.

Adopting Scrum and other Agile methodologies can be a significant shift for any organization, which is where an Agile coach assists. Agile coaches work closely with Scrum teams to guide them through the transition and guide team members to apply Scrum principles in their daily work. 

They facilitate Scrum events, such as sprint planning and retrospectives, and coach teams on best practices for collaboration and communication. Agile coaches play a key role in removing obstacles hindering a team’s progress.

The main goal is allowing Scrum teams to focus on delivering value. By providing tailored training and support, Agile coaches empower team members to embrace Agile practices.

This will foster a culture of continuous improvement and enhance the Scrum team’s effectiveness across multiple teams and projects.

Even experienced Scrum teams face challenges like resistance to change, unclear direction, and limited Scrum training. Starting small, with one project or team, can help overcome these hurdles.

Comprehensive training and ongoing coaching boost confidence in Scrum and Agile methods. Clear goals, roles, and responsibilities keep everyone aligned.

Regular retrospectives and feedback sessions help teams reflect, adapt, and improve. By tackling these challenges early, Scrum teams can build resilience, collaborate better, and succeed with the Scrum framework.

Tracking the progress and effectiveness of a Scrum team is essential for continuous improvement and project success. Scrum teams often use sprint velocity, burn-down charts, and customer satisfaction scores to gauge performance. 

Monitoring lead time, cycle time, and defect density can also provide insights into the team’s workflow and product quality. Regular sprint reviews and retrospectives are key Scrum events.

These reviews allow teams to reflect on their achievements, identify areas for growth, and celebrate successful sprint completion. By consistently measuring these indicators and acting on feedback, Scrum teams enhance their practices, deliver greater customer value, and ensure ongoing success with the Scrum framework.

The Scrum framework itself is simple. The rules, artifacts, events, and roles are easy to understand. Its semi-prescriptive approach helps remove the ambiguities in the development process.

However, it also gives sufficient space for companies to introduce their individual flavor. The organization of complex tasks into manageable user stories makes it ideal for complex projects. 

The clear demarcation of roles and planned events ensures transparency and collective ownership throughout the development cycle. Quick releases keep the team motivated and the users happy, as they can see progress in a short amount of time.

However, Scrum could take time to understand fully, especially if the development team is acclimated to a typical waterfall model. Smaller iterations, daily Scrum meetings, sprint reviews, and identifying a Scrum master could be a challenging cultural shift for a new team.

However, the long-term benefits far outweigh the initial learning curve. Scrum's success in developing complex hardware and software products across diverse industries and verticals makes it a compelling framework to adopt for your organization.

To learn Scrum with Jira, check out this tutorial.