U.S Department of Veterans Affair

Agile Methodology: Using Scrum Framework


provided by AgileAtlas.org.

Values from the Agile Manifesto

Scrum is the best-known of the Agile frameworks. It is the source of much of the thinking behind the values and principles of the Agile Manifesto, which form a common basis for all of these approaches. Please see the Manifesto for more information.

The Agile Manifesto values apply directly to Scrum:

  • Individuals and interactions over processes and tools. Scrum, like all the Agile Frameworks and Methods, relies directly on trust in teams, the individuals in the teams, and the way they interact. Teams figure out what is to be done, teams figure out how to do it, and teams do it. Teams identify what's getting in their way, and they take the responsibility to resolve all the difficulties that are within its scope. Teams work with other parts of the organization to resolve the concerns that are outside of their control - which is critical. Trying to follow the Scrum Framework but undermining the primary focus on team responsibility will not yield optimal results.
  • Working software over comprehensive documentation. Scrum requires a working, finished increment of the product as the primary result of every Sprint. Certainly there will be analysis work, design work and testing work, all of which may need to be documented. But it is the working software that allows the organization to guide the project to success. Scrum teams must produce a product increment in every Sprint.
  • Customer collaboration over contract negotiation. The Scrum Product Owner is the Scrum Team's prime point of contact with the eventual end users of the product, and with the parts of the organization that need the product. The Product Owner is a member of the team and works collaboratively with the team to determine what needs to be done. In this collaboration, the Product Owner selects the most valuable next steps, ensuring that the product has the highest possible value at every point in the process. It is critical that the Product Owner builds a rich collaboration with their team.
  • Responding to change over following a plan. Everything about Scrum is designed to make sure that everyone has the information needed to make good decisions about the project. The project's progress is represented by a real, running, product increment. The backlog of items to be accomplished is available for all to see. Progress, both overall and Sprint by Sprint, is clearly visible. Problems and concerns are discussed openly and dealt with immediately. This is critical. Scrum works well for teams that openly "inspect" what's going on and "adapt" their actions to the reality.

Srum Framework

Scrum is a framework for building a product and the framework begins when stakeholders need a product. Scrum is a team process that includes the following roles: the Product Owner, the ScrumMaster, and the members of the Development Team. The Product Owner is responsible for deciding what work will be done. The ScrumMaster acts as a servant leader, helping the team and the organization make the best use of Scrum. The Development Team builds the product incrementally, in a series of short time periods called Sprints. A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals. In each Sprint the Scrum Team will build and deliver a Product Increment. Each increment is a recognizable, visibly improved, operating subset of the product, meeting understood acceptance criteria and built to a level of quality called the Definition of Done.

Scrum includes three essential artifacts, the Product Backlog, the Sprint Backlog, and the Product Increment. The Product Backlog is the ordered list of ideas for the product, kept in the order in which the product will be build. The Sprint Backlog is the detailed plan for development in the next Sprint. The Product Increment is an integrated version of the product, kept at high enough quality to be shippable if the Product Owner chooses to ship it - it is a required result of every Sprint. In addition to these two artifacts, Scrum requires transparency within the team and with the stakeholders. As such, the Scrum Team produces visible displays of plans and progress. Scrum includes five Activities or meetings. These are Product Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

Srum Roles

Role: Product Owner

The Product Owner is the single individual who is responsible for drawing out the most valuable product by the desired date. This is done by managing the flow of work into the team, selecting and refining items from the Product Backlog. The Product Owner maintains the Product Backlog and ensures that everyone knows its contents and what the priorities are. The Product Owner may be supported by other individuals but the position must be filled by a single person.

Certainly the Product Owner is not solely responsible for everything. The whole Scrum Team is responsible for being as productive as possible, for improving their practices, for asking the right questions and for helping the Product Owner, and so on. The Development Team is responsible for determining how much work will be taken on in a Sprint, and for producing a usable Product Increment in every Sprint.

Nonetheless, the Product Owner, in Scrum, is in a unique position. The Product Owner is typically the individual closest to the "business side" of the project. The Product Owner is charged by the organization to "get this product out", and is usually the person who is expected to do the best possible job of satisfying all the stakeholders. He or she does this by managing the Product Backlog, and by ensuring that the Product Backlog, and progress against it, is kept visible.

The Product Owner, by choosing what the Development Team should do next and what to defer, makes the scope versus schedule decisions to lead to the best possible product.

Role: Development Team Member

The Development Team is made up of the professionals who do the work of delivering the Product Increment. They self-organize to accomplish the work and are expected to be available to the project full time.

Scrum requires that the Development Team be a cross-functional group of people who, among them, have all the necessary skills to deliver each increment of the product. The Development Team members have the responsibility to self-organize to accomplish the Sprint goal, producing each new Product Increment according to each Sprint Plan.

The Development Team members forecast how much they can do in one Sprint, and they decide how they are going to accomplish it.

Role: ScrumMaster

The ScrumMaster is a "servant leader", helping the rest of the Scrum Team follow their process. The ScrumMaster must have a good understanding of the Scrum Framework and the ability to train others in its subtleties.

The ScrumMaster works with the Product Owner to help him or her understand how to create and maintain the Product Backlog. He works with the Development Team to find and implement the technical practices that will allow them to get to done at the end of each Sprint. He works with the whole Scrum Team to evolve the Definition of Done.

Another responsibility of the ScrumMaster is to ensure that impediments to the team’s progress are removed. These impediments may be external to the team, such as a lack of support from another team, or internal, such as the Product Owner not knowing how to properly prepare the Product Backlog.

The ScrumMaster fosters self-organization. Issues should be removed by the team wherever possible.

The ScrumMaster acts as a coach for the Scrum Team, helping them to execute the Scrum process. He or she helps them to work together and to learn the Scrum framework, and protects them from both internal and external distractions. He or she may facilitate meetings, and helps keep the Scrum Team on track, productive, and growing in ability.

The ScrumMaster is responsible for ensuring that Scrum is understood and in place, inside the team and outside. He or she helps people outside the team understand the process, and understand which interactions with the team are helpful and which are not. The ScrumMaster helps everyone improve to make the Scrum Team more productive and valuable.

Artifact: Product Backlog

The Product Backlog is an essential artifact in Scrum. The Product Backlog is an ordered list of ideas for the product, kept in the order in which they are expected to be accomplished. It is the single source from which all requirements flow. This means that all work the Development Team does comes from the Product Backlog. Every feature idea, enhancement, bug fix, documentation requirement - every bit of work they do ‐ is derived from a Product Backlog item. Each item on the Product Backlog includes a description and an estimate.

The Product Backlog may begin as a large list or a short one. It may be vague or rather detailed. Typically it begins short and vague and becomes longer and more concrete as time goes on. Product Backlog items slated for implementation soon will be "refined": clarified, better defined, split into smaller chunks, as part of the Product Backlog Refinement activity.

The Product Owner is responsible and accountable for maintaining the Product Backlog and, the Product Owner may ‐ and should ‐ have help in producing and keeping it up to date. Product Backlog items may originate from the Product Owner, from team members or from other stakeholders.

Activity: Product Backlog Refinement

Since Product Backlog Items are quite often large and general in nature, and since ideas come and go and priorities change, Product Backlog Refinement is an ongoing activity throughout a Scrum project. This activity includes but is not limited to:

  • Keeping the Product Backlog ordered;
  • Removing or demoting items that no longer seem important;
  • Adding or promoting items that arise or become more important;
  • Splitting items into smaller items;
  • Merging items into larger items; and
  • Estimating items.

One key benefit of the Product Backlog Refinement activity is to prepare for the upcoming Sprints. In aid of this, the refinement activity gives special attention to preparing items that are approaching for implementation. There are many things to consider, including but not limited to:

  • Each item entering the Sprint should ideally represent an increment of "business value".
  • The Development Team needs to be able to build each item within a single Sprint; and
  • Everyone needs to understand what is intended.

Depending on the nature of the product, other skills and inputs may be needed. In every case, Product Backlog Refinement is best considered as an activity for all the team members, not just the Product Owner.

Activity: Sprint Planning

Each Sprint begins with a time-boxed meeting called Sprint Planning. In this meeting the Scrum Team collaborates to select and understand the work to be done in the upcoming Sprint.

The entire team attends the Sprint Planning meeting. Working from the ordered Product Backlog, the Product Owner and the Development Team Members discuss each item and come to a shared understanding of that item and what is required to complete it consistent with the current Definition of Done. All Scrum meetings are time-boxed. The recommended time for the Sprint Planning meeting is one hour per week of Sprint duration. Because the meeting is time-boxed, the success of the Sprint Planning meeting is highly dependent upon the quality of the Product Backlog going in. This is why Product Backlog Refinement is an important Scrum activity.

In Scrum, the Sprint Planning meeting is described as having two parts:

  1. Determine what work will be completed in the Sprint; and
  2. Determine how the work will be accomplished.
Part One: What Work Will be Done?

In the first part of the meeting, the Product Owner presents ordered Product Backlog items to the Development Team, and the whole Scrum Team collaborates to understand the work.

The number of Product Backlog items to undertake in the Sprint is solely up to the Development Team. To decide how many items to undertake, the Development Team considers the current state of the Product Increment, the past performance of the team, the team's current capacity, and the ordered Product Backlog. The Development Team alone decides how much work to take on. Neither the Product Owner, nor any other agency, can push more work onto the Development Team.

Often, but not always, the Sprint is given a goal, called the Sprint Goal. This is a very strong practice that helps everyone focus more on the essence of what needs to be done, and less on small details which may not be important to what the team needs to accomplish.

Part Two: How Will the Work Be Accomplished?

In the second part of the meeting, the Development Team collaborates to decide how to produce the next Product Increment in accord with the current Definition of Done. They do sufficient design and planning to be confident of completing the work during the Sprint. Work to be done in the early days is broken down into small units of one day or less. Work to be done later may be left in larger units to be decomposed later.

Deciding how to do the work is the responsibility of the Development Team, just as deciding what to do is the responsibility of the Product Owner.

The Product Owner may be readily available during this part of the meeting to answer questions and resolve misunderstandings.

Result of Sprint Planning

Sprint Planning concludes with the Scrum Team coming to a common understanding of the quantity and complexity of what is to be accomplished during the Sprint, and within a rational range of circumstances, expect to complete it. The Development Team forecasts the amount of work they will complete and commit to each other to accomplish it.

To sum up: in the Sprint Planning Meeting, the Development Team

  • Considers and discusses Product Backlog Items with the Product Owner;
  • Ensures that they understand them;
  • Selects a number of items that they forecast they can accomplish; and
  • Creates a sufficiently detailed plan to be sure they can accomplish the items.

The resulting list of things to do is the "Sprint Backlog".

Artifact: Sprint Backlog

The Sprint Backlog is the list of refined Product Backlog items chosen for development in the current Sprint. The Sprint Backlog forecasts what work will be completed in the Sprint, including a plan for accomplishing the work.

With the Sprint Backlog in place, the Sprint begins, and the Development Team develops the new Product Increment defined by the Sprint Backlog.


During the Sprint, the Development Team self-organizes to produce a Product Increment in accord with the Sprint Backlog, as determined during Sprint Planning. Self-organizing means that the team responsibly produces the Product Increment in accord with all the organization's standards, according to the Definition of Done, and that the Development Team determines just how to go about that.

Artifact: Product Increment

The most important Scrum artifact is the Product Increment. Every Sprint produces a Product Increment. The Product Increment must be of high enough quality to be given to users. The Product Increment must meet the Scrum Team's current Definition of Done, and each component of it be acceptable to the Product Owner.

Additional Indicators of Visible Progress

Scrum requires transparency within the team and outside the team. While the Product Increment is the most important way of creating transparency, the Scrum Team will create any other artifacts that are needed to make sure that the status of the project is understood. Common additional artifacts include burn charts and task boards.

Agreement: Definition of Done

When the Product Increment is delivered, it needs to be "done" according to a shared understanding of what "done" means. This definition is different for every Scrum Team, and as the team matures, the Definition of Done will expand and become more stringent.

The Definition of Done must always include the notion that the Product Increment is of high enough quality to be shippable: the Product Owner could choose to release it immediately. The Product Increment includes the functionality of all previous Product Increments and is fully tested so that all completed Product Backlog items continue to work together.

Activity: Daily Scrum

The Development Team is self-organizing. The Development Team uses the Daily Scrum meeting to ensure that they are on track for attaining the Sprint Goal. The meeting takes place at the same time and place every day. Each Development Team member gives three bits of information:

  • What I have accomplished since our last Daily Scrum;
  • What I plan to accomplish between now and our next Daily Scrum; and
  • What is impeding my progress.

There may be brief clarifying questions and answers, but there is no discussion of any of these topics during the Daily Scrum. However, many teams meet right after the Daily Scrum to work on any issues that have come up.

The Daily Scrum is not a report to management, or to the Product Owner, or to the ScrumMaster. It is a communication meeting within the Development Team, to ensure that they are all on the same page. Only the Scrum Team members, including ScrumMaster and Product Owner, speak during this meeting. Other interested parties can come and listen in. Based on what comes up in the meeting, the Development Team reorganizes the work as needed to accomplish the Sprint Goal.

The Daily Scrum is a key element of Scrum, leading to transparency, trust, and better performance. It provides rapid recognition of problems, and promotes the team's self-organization and self-reliance. All Scrum meetings are time-boxed. The recommended time-box for the Daily Scrum is no more than fifteen minutes.

Activity: Sprint Review

At the end of the Sprint, the Scrum Team and stakeholders review the output of the Sprint. All Scrum meetings are time-boxed. The recommended time-box for the Sprint Review is one hour per week of Sprint duration.

The central point of discussion is the Product Increment completed during the Sprint. Since the Stakeholders are those who have a "stake" in the results, it is generally wise and helpful for them to attend this meeting. This is an informal meeting to take a look at where we are and to collaborate on how we might go forward. Everyone has input at the Sprint Review. Naturally, the Product Owner makes the final decisions about the future, updating the Product Backlog as appropriate.

Teams will find their own way to do the Sprint Review. A demonstration of the Product Increment is common. The group often discusses what they observed during the Sprint, what product ideas came to mind. They discuss the state of the Product Backlog and talk about possible completion dates and what might be done by those dates.

The Sprint Review gives everyone present an overview of the current Product Increment. In this light, it is common to update the Product Backlog as part of the Sprint Review.

Activity: Sprint Retrosepctive

At the end of each Sprint, the Scrum Team meets for the Sprint Retrospective. The purpose is to review how things went with respect to the process, the relationships among people, and the tools. The team identifies what went well and not so well, and identifies potential improvements. They develop a plan for improving things in the future. All Scrum meetings are time-boxed. The recommended time-box for the Sprint Retrospective is one hour per week of Sprint duration.

The Scrum Team improves its own process, always remaining within the Scrum Framework.

Rinse, Repeat

The Scrum cycle repeats from here, for every Sprint.


To sum up, the Scrum Team's members, the Product Owner, the Development Team, and the ScrumMaster, collaborate to create a series of Product Increments, at short time-boxed intervals called Sprints, meeting the Product Owner's acceptance criteria and the team's shared "Definition of Done". They work from a Product Backlog. In each Sprint, they begin with Sprint Planning to produce the Sprint Backlog, a plan for the Sprint. They self-organize to do the Development, using Daily Scrum meetings to coordinate and to ensure that they produce the best possible Product Increment. They perform Product Backlog Refinement to prepare for the next Sprint's planning meeting. They end the Sprint with the Sprint Review and Sprint Retrospective, reviewing the product and their process.

Click Image to Enlarge

  • A product owner creates a prioritized wish list called a product backlog.
  • During Sprint planning, the team pulls a small chunk from the top of that wish list, a Sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time, a Sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal.
  • At the end of the Sprint, the work should be potentially shippable (e.g., ready to hand to a customer, put on a store shelf, or show to a stakeholder).
  • The Sprint ends with a sprint review and retrospective.
  • As the next Sprint begins, the team chooses another chunk of the product backlog and begins working again.