Why Use Scrum?

Why Use Scrum
Why Use Scrum?

Why Use Scrum?

Why use scrum in software development? Here are some of the key benefits of Scrum in any project are:

  • Adaptability: Empirical process control and iterative delivery make projects adaptable and open to incorporating change.
  • Transparency: All information radiators like a Scrumboard and Sprint Burndown Chart are shared, leading to an open work environment.
  • Continuous Feedback: Continuous feedback is provided through the Conduct Daily Standup and Demonstrate and Validate Sprint processes.
  • Continuous Improvement: The deliverables are improved progressively Sprint by Sprint, through the Groom Prioritized Product Backlog process.
  • Continuous Delivery of Value: Iterative processes enable the continuous delivery of value through the Ship Deliverables process as frequently as the customer requires.
  • Sustainable Pace: Scrum processes are designed such that the people involved can work at a sustainable pace that they can, in theory, continue indefinitely.
  • Early Delivery of High Value: The Create Prioritized Product Backlog process ensures that the highest value requirements of the customer are satisfied first.
  • Efficient Development Process: Time-boxing and minimizing non-essential work leads to higher efficiency levels.
  • Motivation: The Conduct Daily Standup and Retrospect Sprint processes lead to greater levels of motivation among employees.
  • Faster Problem Resolution: Collaboration and colocation of cross-functional teams lead to faster problem solving.
  • Effective Deliverables: The Create Prioritized Product Backlog process and regular reviews after creating deliverables ensures effective deliverables to the customer.
  • Customer Centric: Emphasis on business value and having a collaborative approach to stakeholders ensures a customer-oriented framework.
  • High Trust Environment: Conduct Daily Standup and Retrospect Sprint processes promote transparency and collaboration, leading to a high trust work environment ensuring low friction among employees.
  • Collective Ownership: The Approve, Estimate, and Commit User Stories process allows team members to take ownership of the project and their work leading to better quality.
  • High Velocity: A collaborative framework enables highly skilled cross-functional teams to achieve their full potential and high velocity.
  • Innovative Environment: The Retrospect Sprint and Retrospect Project processes create an environment of introspection, learning, and adaptability leading to an innovative and creative work environment.

Source: A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK™ Guide), 2013 Edition [1]

For more Scrum articles, please visit our internal page, found here

Why Use Scrum?

Agile Manifesto

Agile Manifesto for Software Development

What is the Agile Manifesto?

The Agile Manifesto is a brief document built on 4 values and 12 principles for agile software development. The Agile Manifesto was published in February 2001 and is the work of 17 software development practitioners who observed the increasing need for an alternative to documentation-driven and heavyweight software development processes.

What Does The Agile Manifesto Say?

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Twelve Principles of Agile Software

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Who Created the Agile Manifesto?

Here are the individuals who signed the original Agile Manifesto back in 2001:

For more information, please visit the Agile Manifesto page or our article page


ScrumAA Glossary

ScrumAA Glossary
ScrumAA Glossary

ScrumAA Glossary

Acceptance Criteria

Details just what needs to be done for the Product Backlog Item to be considered complete. This helps teams estimate, test, and accomplish the work. The concepts of Acceptance Criteria and Definition of Done sound very similar, but they are quite distinct.


Items which represent work or value. There are 3 Artifacts in Scrum; (Product Backlog, Sprint Backlog, and Product Increment).


An ordered, prioritized list of work to be done by the Scrum Team. The Product Owner curates the Backlog.

Backlog Item

An item that represents a piece of work to be done by the Scrum Team.

Backlog Refinement

The ongoing process of adding detail, estimates, and order to items in the Backlog. Refinement usually consumes no more than 10% of the capacity of the Team. However, Backlog Items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Cross-Functional Team

A team with all the competencies needed to accomplish work they are given without outside help. Cross-functional teams are proven to be more flexible, creative, and productive than teams that specialize in only one of the competencies needed to get the work done.


One of the five Scrum Values. People personally commit to achieving the goals of the Scrum Team.

Daily Scrum

One of the 5 Scrum Events, this meeting lasts no more than fifteen minutes and happens every workday at the same appointed time and place. Everyone on the team attends. At this meeting, the information needed to assess progress is presented, and any impediments are noted. This information may result in re-planning of the Sprint.

Definition of Done

The Product Owner states specific requirements and acceptance tests that similar Product Backlog Items must meet in order to be completed.

Definition of Ready

Information needed by the team in order to understand and complete a Product Backlog Item (PBI). Examples include the I.N.V.E.S.T. Criteria. There should be no further conversation or exploration of what is needed for the team to complete the PBI.

Development Team

Also known simply as the Team, it is comprised of people who work on Sprint Backlog Items. It acts as ‘one team’ and has all the skills needed to produce a working tested increment each Sprint. The development team is:

  • Self-Organizing
  • Cross-Functional
  • Accountable
  • Small with 3 – 9 team members


The act of predicting how much effort will be needed to complete work on a Product Backlog Item. But without it Product Owners and Scrum Masters will struggle with securing a release date and showing velocity improvement. There are many methods. Most commonly occurs during Product Backlog Refinement.


Anything that slows the Team down or prevents them from completing work. The key is to identify and remove impediments as quickly and systematically as possible. The Scrum Master helps the team remove impediments and is accountable for surfacing impediments the team can’t remove on their own.


Also commonly referred to as a ‘Potentially Shippable Product Increment.’ It is the sum of all the Product Backlog Items completed during a Sprint. It is one of the three Scrum Artifacts and represents a step towards a vision, product, or goal. Each Sprint must include at least one Increment in order to be considered successful.

INVEST Criteria

An acronym that details the elements an individual Product Backlog Item needs to meet in order to meet the Definition of Ready.

  • V – VALUE
  • S – SMALL

Minimum Viable Product

A version of a product which allows a team to collect the maximum amount of validated learning about customers with the least amount of effort.

Product Owner

One of three Scrum Roles. Responsible for creating a compelling product vision that is executable. Other responsibilities include curating and prioritizing a Product Backlog, spending 50% of their time with customers and stakeholders, and 50% working closely with the team.

Release Planning

Collaboratively agree what is to be achieved by a Scrum of Scrums Team using a longer planning horizon than a single Sprint (usually 1-6 months). A Product Owner Team led event used to acquire funding, drive marketing, and align stakeholder/team expectations. A timeboxed event of no more than 4 hours for a one month period.


A specialized function in a particular situation. In Scrum there are three roles: Product Owner, Scrum Master, and Team Member. This simple structure creates clear accountability and efficient communication while removing unneeded bureaucracy.


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

Scrum Artifacts

There are three Artifacts in Scrum; the Product Backlog, Sprint Backlog, and Increment. Scrum’s artifacts represent work or value. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Sprint Board

A tool that makes visible a Scrum Team’s Sprint Backlog and progress during a Sprint. Can take many forms ranging from a digital tool to a three column board labeled ‘Do’, ‘Doing’, ‘Done’. The board is updated by the Team and shows all items that need to be completed, are in progress, or are finished in the Sprint.

Scrum Master

One of the three roles in Scrum. A servant-leader for the team and the wider organization. Accountable for the removal of impediments and coaching the team in Scrum practices, usually by facilitating Scrum Events. Which is why they own the process in Scrum.

Scrum Team

Consists of a Product Owner, Team Members, and a Scrum Master. They deliver products iteratively and incrementally, maximizing opportunities for feedback. They are also small (3-9 total members) in order to create clear and effective communication. Scrum Teams are:

  • self-organizing
  • cross-functional
  • flexible
  • creative
  • productive

Scrum Values

There are five Scrum Values:

  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect

When these values are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.


One of the five Scrum Events. It is a short, consistent cycle no longer than four weeks. The goal is to have an iteration short enough to keep the team focused but long enough to deliver a meaningful increment of work. All other Scrum Events take place during a Sprint. Once a Sprint is finished, the next begins.

Sprint Backlog

The set of Product Backlog Items selected for the Sprint, plus a plan for delivering the Increment and realizing the Sprint Goal. It includes at least one Improvement identified at the last Sprint Retrospective. It makes visible all of the work the Team identifies as necessary to meet the Sprint Goal.

Sprint Goal

An objective set for the Sprint that can be met through the completion of Sprint Backlog Items. It provides guidance on why the Increment is being built.

Sprint Planning

One of the five Scrum Events. Where the work to be performed in the Sprint is planned. This event is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

Sprint Retrospective

One of the five Scrum Events. An opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. This event occurs after the Sprint Review and prior to the next Sprint Planning. At most a three-hour meeting for one-month Sprints.

Sprint Review

One of the five Scrum Events. Held at the end of the Sprint to allow customers and stakeholders to inspect the Increment, give feedback, and for the Scrum Team to adapt the Product Backlog if needed. This is at most a four-hour meeting for one-month Sprints.

Story Points

Used by Scrum Teams in estimation, an abstract measure of the relative effort required to complete a given Product Backlog Item (PBI). A commonly used type of estimation uses story points and the Fibonacci sequence to quickly generate accurate estimates for PBI’s.


A fixed, maximum length of time for an activity or event. Scrum uses timeboxing for all of the Scrum events and as a tool for concretely defining open-ended or ambiguous tasks.


A measure of the amount of work a Scrum Team can accomplish during a single Sprint. An important metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed Sprint Backlog Items.

For more questions, please feel free to visit our Articles page

More Scrum info can be found in the Scrum Guide


ScrumAA FAQs

Frequently Asked Questions in Scrum (FAQs)

ScrumAA FAQs
ScrumAA FAQs
  • ScrumAA Frequently Asked Questions (FAQs)
What is the difference between Scrum and Agile?Agile Development is a software methodology, where Scrum is one of the Agile processes frameworks
What are 5 Scrum values?Per The Scrum Guide, all Scrum teams must share these values: commitment, courage, focus, openness, and respect
How long is a sprint in Agile?A sprint should be anywhere from a minimum of 1 to a maximum of 4 weeks
Who decides the sprint length?According to the Scrum Guide, it is the Scrum Team
Who is in the Scrum Team?The Product Owner, the Scrum Master, and the Development Team
What is sprint 0 in Scrum?When a scrum team sets out to adopt Scrum for the first time, the first scrum is usually called Sprint 0
Can a Scrum Team change the sprint duration?While it is not recommended to do so, yes the team can change the sprint duration but the team’s velocity will have to be adjusted.
How long is the daily scrum?15 minutes maximum
Can the Product Owner and the ScrumMaster’s roles be played by the same person?No. It is very not recommended
ScrumAA Frequently Asked Questions (FAQs)

For more questions, please feel free to visit our Articles page

More Scrum info can be found in the Scrum Guide

The 4 Amazing Scrum Events

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

The Scrum Events

Per Scrum Guide, prescribed events are used to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Scrum Events Table
Scrum Events

Sprint Planning

Sprint Planning is one of the Scrum events where the work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

Daily Scrum

The Daily Scrum/Standup is a 15-minute time-boxed event for the Development Team. The Daily Standup is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Standup is held at the same time and place each day to reduce complexity for the team to answer the following questions:

  1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
  2. What will I do today to help the Development Team meet the Sprint Goal?
  3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Sprint Review

A Sprint Review is one of the Scrum events that is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

The Sprint Review includes the following elements:

  1. Attendees include the Team and key stakeholders invited by the Product Owner;
  2. The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
  3. The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  4. The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
  5. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

Sprint Retrospective

The Sprint Retrospective is one of the Scrum events and it is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

The purpose of the Sprint Retrospective is to:

  1. Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  2. Identify and order the major items that went well and potential improvements; and,
  3. Create a plan for implementing improvements to the way the Scrum Team does its work

Scrum Sprint

Scrum Sprint
  • Scrum Sprint
  • Cancelling a Sprint
  • Sprint Goal

Scrum Sprint

So what is the definition of a Scrum Sprint? According to the Scrum Guide, the heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Scrum Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Scrum Sprint:

  1. No changes are made that would endanger the Sprint Goal;
  2. Quality goals do not decrease; and,
  3. Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Scrum Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Scrum Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Scrum Sprint
Scrum Sprint

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

ScrumAA articles are derived from the Scrum Guide

Go back to the blog’s page for more articles.

You can also check our Wiki page for more additional information regarding Scrum knowledge in general and definitions by clicking this link.

What is a User Story?

What is a User Story
  • User Story Definition
  • User Story Template: Role-Action-Benefit
  • User Story Examples
  • The 3 C’s (Card, Conversion, Confirmation) of User Stories
  • How to Write Good User Story with INVEST Guidelines

User Story Definition

So what is a User Story? In software development and product management, a User Story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. They are often recorded on index cards, on Post-it notes, or digitally in project management software Depending on the project, user stories may be written by various stakeholders including clients, users, managers, or development team members.

What is a User Story
What is a User Story

User stories are a type of boundary object. They facilitate sense making and communication; that is, they help software teams organize their understanding of the system and its context. [1]

User Story Template: Role-Action-Benefit

A User story only capture the essential elements of a requirement in the format “As a <who> I want <what> so that <benefit>”:

As a Role {Who}, I want to Action {What}, (so that Benefit {Why})

Role – The user should be an actual human who interacts with the system.

  • Be as specific as possible
  • The development team is NOT a user

Action – The behavior of the system should be written as an action.

  • Usually unique for each User Story
  • The “system” is implied and does not get written in the story
  • Active voice, not passive voice (“I can be notified”)

Benefits – The benefit should be a real-world result that is non-functional or external to the system.

  • Many stories may share the same benefit statement.
  • The benefit may be for other users or customers, not just for the user in the story [2]

User Story Examples

As <a recruiter> I can <post new jobs> so that <applicants can find those jobs via search>

As <a job seeker> I can <limit who sees my resume> so that <I have privacy>

The 3 C’s (Card, Conversion, Confirmation) of User Stories

  1. Card – a written description of the story used for planning and estimation.
  2. Conversation – Discuss your ideas with others. Let them ask lots of questions. Work together to come up with ideal solutions. The goal is to build shared understanding.
  3. Confirmation – Work towards agreement on what to build. Record that agreement as a set of confirmation tests.

How to Write Good User Story with INVEST Guidelines

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).

User Story INVEST acronym

I – Independent

Each User Story should represent a distinct and independent set of business value such that, were it released on its own, it would deliver incremental value over the previous state.

N – Negotiable

While the end-goal may be clearly described, the methods by which that goal is achieved should be negotiable – between the Product Owner and the Development Team, the Product Owner and the Customer, or any other involved stakeholders – so as to prevent unrealistic constraints on the feature or functionality.

V – Valuable

The business value of any User Story should be readily recognizable by reading the story, and each story should represent some sort of value to a specific user type.

E – Estimable

We must have enough information that we can properly size a story so that we may properly plan and commit to our work. (But no more!)

S – Small

User Stories should be small enough that they are able to be completed within a sprint.

T – Testable

All members of the team need a clear and precise way to verify whether or not a User Story has been completed

More articles from ScrumAA can be found here

Also check out Wikipedia for more information


[1] https://en.wikipedia.org/wiki/User_story

The Scrum Framework

Scrum Framework

What is the Scrum Framework

The Scrum Framework in Scrum, is the prescribed events that are used to create regularity. All events are time-boxed events, such that every event has a maximum duration. The events are described more elaborately below.


The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a potentially releasable product increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints consist of the Sprint planning, daily scrums, the development work, the Sprint review, and the Sprint retrospective.

Sprint planning

The work to be performed in the Sprint is planned collaboratively by the Scrum Team.

Daily Scrum Meeting

This is a 15-minute time-boxed event for the Scrum Team to synchronize the activities and create a plan for that day.

Sprint Review

This is held at the end of the Sprint to inspect the Increment and make changes to the Product Backlog, if needed.

Sprint Retrospective

Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. In this meeting, the Scrum Team is to inspect itself and create a plan for improvements to be enacted during the subsequent Sprint.

The Scrum Framework
The Scrum Framework

More articles from ScrumAA can be found here



The Scrum Team

Scrum Team

Structure of the Scrum Team

The Scrum team includes the:

  • Product Owner
  • Scrum Master, and
  • Development team
The Scrum Team
The Scrum Team

The team share different tasks and responsibilities related to the delivery of the product. Each role are closely inter-related. It is recommended for Scrum team members work together in the same location whenever possible. Let’s take a look at each of these roles in terms of their responsibilities, authority, and characteristics.

Product Owner

The Product Owner is the Team member who knows what the customer wants and the relative business value of those wants. He or she can then translate the customer’s wants and values back to the Scrum team. The Product Owner must know the business case for the product and what features the customers’ wants. He must be available to consult with the team to make sure they are correctly implementing the product vision. Most importantly, he must have the authority to make all decisions necessary to complete the project, in other words, the Product Owner is responsible for managing the Product Backlog which includes:

  1. Expressing Product Backlog items clearly.
  2. Ordering the Product Backlog items to best achieve goals and missions.
  3. Optimizing the value of the work the Team performs.
  4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team will work on further.
  5. Ensuring that the Team understands items in the Product Backlog to the level needed.

Scrum Master

The scrum master help to keep the team accountable to their commitments to the business and also remove any roadblocks that might impede the team’s productivity. They met with the team on a regular basis to review work and deliverables, most often in a weekly cadence. The role of a scrum master is to coach and motivate team member, not enforce rules to them. The role of a scrum master includes:

  1. Ensure the process run smoothly
  2. Remove obstacles that impact productivity
  3. Organize the critical events and meeting

Development Team

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

  1. They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  2. Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
  3. Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
  4. Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations or business analysis; and,
  5. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

ScrumAA articles are derived from the Scrum Guide

This article, due to it’s importance, was copied entirely from here

Go back to the blog’s page for more articles

Why Scrum?

Why Scrum

ScrumAA Articles: Why Scrum?

Why Scrum
Why Scrum

Author: ScrumAA

  1. Scrum is an iterative and incremental agile software development methodology for managing product development.
  2. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”, challenges assumptions of the “traditional, sequential approach” to product development
  3. Scrum enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project.

ScrumAA articles are derived from the Scrum Guide

Go back to the blog’s page for more articles

Secured By miniOrange