About Scrum

Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum's roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

Scrum Overview

Scrum (n): 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
- Extremely difficult to master
Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

Which statement best describes Scrum?
A) A complete methodology that defines how to develop software.
B) A cookbook that defines best practices for software development.
C) A framework within which complex products in complex environments are developed. *
D) A defined and predictive process that conforms to the principles of Scientific Management.

An organization has decided to adopt Scrum, but management wants to change the terminology to fit with terminology already used.
What will likely happen if this is done?
A) Without a new vocabulary as a reminder of the change, very little change may actually happen.
B) The organization may not understand what has changed within Scrum and the benefits of Scrum may be lost.
C) Management may feel less anxious.
D) All answers apply. *

Scrum Framework

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum's success and usage.
Specific strategies for using the Scrum framework vary and are described elsewhere.
The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.

Scrum Definitions

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Transparency

​Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
For example:
- A common language referring to the process must be shared by all participants; and,
- A common definition of "Done" must be shared by those performing the work and those accepting the work product.

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

Adaptation

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Scrum prescribes four formal opportunities for inspection and adaptation, as described in the Scrum Events section of this document.
- Sprint Planning Meeting
- Daily Scrum
- Sprint Review
- Sprint Retrospective​

Done

When the Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the "Definition of Done" for the Scrum Team and is used to assess when work is complete on the product Increment.
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of "Done".
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
As Scrum Teams mature, it is expected that their Definition of "Done" will expand to include more stringent criteria for higher quality.​

When many Development Teams are working on a single product, what best describes the definition of "done"?
A) Each Development Team defines and uses its own. The various differences are discussed and reconciled during the stabilization phase.
B) Each Development Team uses its own but must make it clear to all other Teams if there are differences.
C) All Development Teams must have a definition of "done" that when their work integrates results in a definition of "done" that is potentially releasable. *
D) It depends.

Impediment

Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily Scrum meeting. The Scrum Master is charged with ensuring impediments get resolved. Scrum Masters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.​

A Scrum Master is keeping a list of open impediments, but it is growing and he/she has been able to resolve only a small portion of the impediments.
Which three techniques would be most helpful in this situation?
A) Prioritize the list and work on them in order.
B) Alert management to the impediments and their impact. *
C) Arrange a triage meeting with all other project managers.
D) Discuss the absence of management support with the Development Team.
E) Tell the Product Owner that Scrum isn't working.
F) Consult with the Development Team.

Velocity

In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
Once established, velocity can be used to plan projects and forecast release and product completion dates.
How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates.

Scrum Team

Scrum does not have a role called "project manager".
A) True *
B) False
 
Who is on the Scrum Team?
Feedback: The Scrum Team consists of the Scrum Master (manages the process) the Product Owner (decides what to do) and the Development Team (does the work).
A) The Scrum Master *
B) The Product Owner *
C) The Development Team *
D) Project Manager
E) None of the above

The Development Team should have all the skills needed to:
A) Complete the project as estimated when the date and cost are committed to the Product Owner.
B) Do all of the development work, but not the types of testing that require specialized testing, tools, and environments.
C) Turn the Product Backlog it selects into an increment of potentially shippable product functionality. *

Development Team membership should change:
A) Every Sprint to promote shared learning.
B) Never, because it reduces productivity.
C) As needed, while taking into account the short term reduction in productivity. *
D) Just as it would on any development team, with no special allowance for changes in productivity.

What is the primary way a Scrum Master keeps a Development Team working at its highest level of productivity?
A) By facilitating Development Team decisions and removing impediments. *
B) By ensuring the meetings start and end at the proper time.
C) By preventing changes to the Backlog once the Sprint begins.
D) By keeping high value features high in the Product Backlog.

What is the recommended size for a Development Team (within the Scrum Team)?
Feedback: Optimal Development Team size is small enough to remain nimble and large enough to complete significant work.
Fewer than three Development Team members decreases interaction and results in smaller productivity gains.
More than nine members simply requires too much coordination.
A) 3 plus or minus 1.
B) 6 plus or minus 3. *
C) 9 plus or minus 2.
D) 15 plus or minus 3.

When a Development Team determines that it has over-committed itself for a Sprint, who has to be present when reviewing and adjusting the Sprint work selected?
A) The Scrum Master, project manager and Development Team.
B) The Product Owner and Development Team. *
C) The Product Owner and all stakeholders.
D) The Development Team.

Scrum Team Roles

There are three essential roles in any Scrum project:
-    Product Owner
-    Scrum Master
-    Team

Which of the below are roles on a Scrum Team?
A) Development Team *
B) Users
C) Customers
D) Product Owner *
E) Scrum Master *

What is the role of "Management" in Scrum?
Feedback: However, management external to the Scrum team is incredibly important in setting the vision and strategy to guide the overall direction of the business.
A) To continually monitor staffing levels of the Development Team.
B) To monitor the Development Team's productivity.
C) Management supports the Product Owner with insights and information into high value product and system capabilities.
Management supports the Scrum Master to cause organizational change that fosters empiricism, self-organization, bottom-up intelligence, and intelligent release of software. *
D) To identify and remove people that aren't working hard enough.

Stakeholder Role

The stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews. It can be sponsor to a project, or have an interest or a gain upon a successful completion of a project; may have a positive or negative influence in the project completion. Examples of project stakeholders include the customer, the user group, the project manager, the development team, the testers, etc. Stakeholders are anyone who has an interest in the project. Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. They may also exert influence over the project’s objectives and outcomes.
The project management team must identify the stakeholders, determine their requirements and expectations, and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project.
The following are examples of project stakeholders:
-Project leader
-Project team members
-Upper management
-Project customer
-Resource Managers
-Line Managers
-Product user group
-Project testers

Manager Role

People who control the environment.

Chicken Role

This person's role is only involved.

Pig Role

This person's role is fully committed.

Product Owner Role

In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions. This person must be available to the team at any time, but especially during the sprint planning meeting and the sprint review meeting. Challenges of being a product owner: Resisting the temptation to "manage" the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself. Resisting the temptation to add more important work after a Sprint is already in progress. Being willing to make hard choices during the sprint planning meeting. Balancing the interests of competing stakeholders.
Scrum Master Role
The Scrum Master is a facilitator for the team and product owner. Rather than manage the team, the Scrum Master works to assist both the team and product owner in the following ways: Remove the barriers between the development and the product owner so that the product owner directly drives development. Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum. Improve the lives of the development team by facilitating creativity and empowerment. Improve the productivity of the development team in any way possible. Improve the engineering practices and tools so that each increment of functionality is potentially shippable. Keep information about the team's progress up to date and visible to all parties. Source: Agile Project Management with Scrum, Ken Schwaber.

Who should know the most about the progress toward a business objective or a release, and be able to explain the alternatives most clearly?
A) The Product Owner. *
B) The Development Team.
C) The Scrum Master.
D) The Project Manager.

Which statement best describes a Product Owner's responsibility?
A) Optimizing the Return on Investment (ROI) and the Total Cost of Ownership (TCO) of the work the Development Team does. *
B) Directing the Development Team.
C) Managing the project and ensuring that the work meets the commitments to the stakeholders.
D) Keeping stakeholders at bay.

Scrum Master is a "management" position?
Feedback: The Scrum Master manages the Scrum process.
If the Scrum Master is not a management position, he or she may not have the influence to remove impediments.
The Scrum Master does not manage the team.
A) True *
B) False 

Team Member Role

A team (or "Scrum team") is optimally comprised of seven plus or minus two people. For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called "cross-functional project teams". Agile practices also encourage cross-functional team members. During a sprint, the team self-organizes to meet the sprint goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The Scrum Master acts as a guardian to ensure that the team is insulated from the product owner. Scrum also advocates putting the entire team in one team room.

Scrum Master Services

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Scrum Master Services To The Organization

The Scrum Master serves the organization in several ways, including:
- Leading and coaching the organization in its Scrum adoption;
- Planning Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact Scrum and empirical product development;
- Causing change that increases the productivity of the Scrum Team; and,
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.​

Scrum Master Services To The Product Owner

The Scrum Master serves the Product Owner in several ways, including:
- Finding techniques for effective Product Backlog management;
- Clearly communicating vision, goals, and Product Backlog items to the Development Team;
- Teaching the Scrum Team to create clear and concise Product Backlog items;
- Understanding long-term product planning in an empirical environment;
- Understanding and practicing agility; and,
- Facilitating Scrum events as requested or needed.​

Scrum Master Services To The Development Team

The Scrum Master serves the Development Team in several ways, including:
- Coaching the Development Team in self-organization and cross-functionality;
- Teaching and leading the Development Team to create high-value products;
- Removing impediments to the Development Team’s progress;
- Facilitating Scrum events as requested or needed; and,
- Coaching the Development Team​ in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Scrum uses time-boxed events, such that every event has a maximum duration. This ensures an appropriate amount of time is spent planning without allowing waste in the planning process.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

What does it mean to say that an event has a time-box?
A) The event must happen at a set time.
B) The event must happen by a given time.
C) The event must take at least a minimum amount of time.
D) The event can take no more than a maximum amount of time. *

Sprint Planning Meeting

The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint. The product owner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the uncommitted backlog to the sprint. Often new backlog items are defined during the meeting. This portion of the sprint planning meeting is time-boxed to four hours. Typically the team will then excuse the product owner from the room and break the backlog Items down into tasks. The product owner is expected to be on call during this phase (previously called the sprint definition meeting) for renegotiation or to answer questions that affect the time estimates. This portion of the sprint planning meeting is time-boxed to four hours. Sometimes teams insert placeholder tasks (with rough estimates) for the product backlog items they don't expect to start working until later in the sprint.

The time-box for the complete Sprint Planning meeting is?
A) 4 hours.
B) 8 hours for a monthly Sprint, proportionately less for shorter Sprints. *
C) Whenever it is done.
D) Monthly.

Sprint Daily Meeting

A fifteen-minute daily meeting for each team member to answer three questions: "What have I done since the last Scrum meeting? (i.e. yesterday)" "What will I do before the next Scrum meeting? (i.e. today)" "What prevents me from performing my work as efficiently as possible?" The Scrum Master ensures that participants call sidebar meetings for any discussions that go too far outside these constraints. The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.

Why is the Daily Scrum held at the same time and same place?
A) The place can be named.
B) The consistency reduces complexity and overhead. *
C) The Product Owner demands it.
D) Rooms are hard to book and this lets it be booked in advance.

The time-box for a Daily Scrum is?
A) The same time of day every day.
B) Two minutes per person.
C) 4 hours.
D) 15 minutes. *
E) 15 minutes for a 4 week sprint, proportionally less for shorter sprints.

Who is required to attend the Daily Scrum?
Feedback: Only the people doing the work described on the Sprint Backlog need to inspect and adapt at the Daily Scrum.
If the Scrum Master or Product Owner is also on the Development Team, they will need to be at the Daily Scrum.
Otherwise, the Scrum Master simply has to make sure the Development Team knows how to conduct a Daily Scrum and does so.
A) The Development Team. *
B) The Scrum team.
C) The Development Team and Scrum Master.
D) The Development Team and Product Owner.
E) The Scrum Master and Product Owner.

The reason the Scrum Master is at the Daily Scrum is:
A) To make sure everyone answers the three questions in order of seniority.
B) He or she does not have to be there; he or she only has to ensure the Development Team has a Daily Scrum. *
C) To write down any changes to the Sprint Backlog, including adding new items, and tracking progress on the burndown.
D) So he or she knows what to report to management.

Sprint Retrospective Meeting

The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and Scrum Master meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting. The sprint retrospective should be time-boxed to three hours. Kelley Louie (Certified Scrum Practitioner) writes: "The sprint retrospective meeting is an integral part of the inspect and adapt process. Otherwise, the team will never be able to improve their overall output and not focus on the overall team performance. The Scrum Master must pay attention to this meeting and work towards resolving the impediments that may be slowing down the team."

Sprint Review Meeting

A Sprint Review 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. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. For example, two week Sprints have two-hour Sprint Reviews. The Sprint Review includes the following elements:  The Product Owner identifies what has been “Done” and what has not been “Done”;  The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
-The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
-The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
-The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Which statement best describes the Sprint Review?

Feedback: Every event in Scrum, besides the Sprint which is a container for the other events, is an opportunity to Inspect AND Adapt.

A) It is a review of the team's activities during the Sprint.

Missed correct answer

B) It is when the Scrum Team and stakeholders inspect the outcome of the Sprint and figure out what to do in the upcoming Sprint. *

C) It is a demo at the end of the Sprint for everyone in the organization to provide feedback on the work done.

D) It is used to congratulate the Development Team if it did what it committed to doing, or to punish the Development Team if it failed to meet its commitments.

The maximum length of the Sprint Review (its time box) is:
A) 2 hours.
B) 4 hours for a monthly Sprint, proportionally less for shorter Sprints. *
C) As long as needed.
D) 1 day.

Sprint Cancelling

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 has to regroup in another Sprint Planning Meeting to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

An abnormal termination of a Sprint is called when?
A) When it is clear at the end of a Sprint that everything won't be finished.
B) When the Team feels that the work is too hard.
C) When Sales has an important opportunity.
D) When the Product Owner determines that it makes no sense to finish it. *

Sprint Event

An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of product must be produced each sprint.

The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the sprint (one per day). At the end of the sprint we have a sprint review meeting, followed by a sprint retrospective meeting.

During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep.

Out of practical necessity, some teams choose to bend this rule by declaring some team members 80 percent available at the outset so they still have some cycles left for "Priority One" bugs and emergencies. But this is a slippery slope and should be avoided whenever possible.

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.
Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint:
- No changes are made that would affect the Sprint Goal;
- Development Team composition remains constant;
- Quality goals do not decrease; and,
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Each 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 definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.
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 goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

When is a Sprint over?
A) When all Product Backlog items meet their definition of done.
B) When the Product Owner says it is done.
C) When all the tasks are completed.
D) When the time-box expires. *

Who is responsible for updating the work estimates during a Sprint?
A) The Development Team. *
B) The Scrum Master.
C) The Product Owner.
D) The most junior member of the Team.

Which two (2) things does the Development Team not do during the first Sprint?
A) Deliver an increment of potentially shippable functionality.
B) Nail down the complete architecture and infrastructure. *
C) Develop and deliver at least one piece of functionality.
D) Develop a plan for the rest of the project. *

What is the maximum length of a Sprint?
Feedback: All of these choices are appropriate fodder in determining the length of the Sprints.
A) Not so long that the risk is unacceptable to the Product Owner.
B) Not so long that other business events can't be readily synchronized with the development work.
C) No more than one calendar month.
D) All of these answers are correct. *

Sprint Event First Part

​What will be done this Sprint?
In this part, the Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Sprint Event Second Part

How will the chosen work get done?
Having selected the work of the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during the Sprint Planning Meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting. The Development Team self-organizes to undertake the work in​ the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint.
The Product Owner may be present during the second part of the Sprint Planning Meeting to clarify the selected Product Backlog items and to help make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the Sprint Backlog items with the Product Owner. The Development Team may also invite other people to attend in order to provide technical or domain advice.
By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Product Progress Monitoring

Monitoring Progress Toward a Goal
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least for every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Various trend burn-down, burn-up and other projective practices have been used to forecast progress. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.

Product Backlog Grooming

A Story Time, the team should spend time during a sprint doing product backlog grooming. This is the process of estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories.
-Meetings should not be longer than an hour
-Meeting does not include breaking stories into tasks
-The team can decide how many meetings are needed per week.
The most commonly used method is the planning poker.​​

User Stories

Is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with Agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper note-card. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.),^[1] though primarily it is the task of a product manager to ensure user stories are captured.

User stories are a quick way of handling customer requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.

A user story is an informal statement of the requirement as long as the correspondence of acceptance testing procedures is lacking. Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise determine whether the goals of the user story have been fulfilled. Some formalization finally happens when the developer accepts the user story and the acceptance procedure as a work specific order.

-Role [who wants to/ who needs to]

-Goal/ Desire [wants to do/ wants to]

-Benefit/ Achievement [in order to]

"As a ROLE, I want TO_DO so that I_CAN"

Scrum Artifacts

Scrum’s artifacts represent work or value in various ways that are useful in providing transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a "Done" Increment. You can use templates also.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.​

Release

The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it.

"The product is released to customer or marketplace obligations. The release balances functionality, cost, and quality requirements against date commitments." (Schwaber/Beedle, Agile Software Development with Scrum, p. 80).

Product Backlog

The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog.

During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.​​

The Product Backlog is ordered by:
Feedback: The Product Owner decides what order on the Product Backlog makes the most sense to optimize the value of the work being done by the Development Team.
A) Small items at the top to large items at the bottom.
B) Safer items at the top to riskier items at the bottom.
C) Least valuable items at the top to most valuable at the bottom.
D) Items are randomly arranged.
E) Whatever is deemed most appropriate by the Product Owner. *

Who has the last say on the order of the Product Backlog?
A) The Stakeholders
B) The Development Team
C) The Scrum Master
D) The Product Owner *
E) The CEO

The CEO asks the Development Team to add a "very important" item to the current Sprint.
What should the Development Team do?
Feedback: The items selected for a Sprint Backlog should never change during a Sprint as
they are designated the "most valuable" items by the Product Owner.
A) Add the item to the current Sprint without any adjustments.
B) Add the item to the current Sprint and drop an item of equal size.
C) Add the item to the next Sprint.
D) Inform the Product Owner so he/she can work with the CEO. *

When multiple teams are working together, each team should maintain a separate Product Backlog.
Feedback: Products have one Product Owner, and one Product Backlog, regardless of how many teams are used. Any other set-up makes it difficult for the Development Team to determine what it should work on.
A) True
B) False *

Product Backlog Item

​In Scrum, a product backlog item ("PBI", "backlog item", or "item") is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks.

See also backlog effort estimation unit.

How much work must a Development Team do to a Product Backlog item it selects for a Sprint?
A) As much as it has told the Product Owner will be done for every Product Backlog item it selects in conformance with the definition of done. *
B) As much as it can fit into the Sprint.
C) The best it can do given that it is usually impossible for QA to finish all of the testing that is needed to prove shippability.
D) Analysis, design, programming, testing and documentation.

Sprint Goal

Sprint goals are the result of a negotiation between the product owner and the development team.
Meaningful goals are specific and measurable. Instead of "Improve scalability" try "Handle five times as many users as version 0.8."
Scrum focuses on goals that result in demonstrable product. The product owner is entitled to expect demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.
Have your team commit to goals that anyone will be able to see are met (or not met) at the end of the sprint. At sprint review meetings, the sprint demonstration is conducted after which the team asks the product owner whether (s)he feels the goals were met.
While some specific product backlog items may not be done at the end of a sprint, it should be very unusual for a team not to meet its sprint goals. Scrum requires the team to notify the product owner as soon as it becomes aware it will not meet its goals.
The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.
As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
The Sprint Goal may be a milestone in the larger purpose of the product road-map.

Sprint Backlog

Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.

The Development Team should not be interrupted during the Sprint. The work it selects for the Sprint should not be changed.
The Sprint Goal should remain intact. All of these attributes of a Sprint foster creativity, quality and productivity.
Based on this, which of the following is false?
A) The Product Owner can help clarify or optimize the Sprint when asked by the Development Team
B) The Sprint Backlog and its contents are fully formulated in the Sprint Planning meeting and do not change during the Sprint. *
C) As a decomposition of the selected Product Backlog Items, the Sprint Backlog changes and may grow as the work emerges.
D) The Development Team may work with the Product Owner to remove or add work if it finds it has more or less capacity than it expected.

Sprint Backlog Item

​In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burn-down chart. Tasks are contained by backlog items.

Scrum literature encourages splitting a task into several if the estimate exceeds twelve hours.

Development Team members volunteer to own a Sprint Backlog item:
A) At the Sprint planning meeting.
B) Never. All Sprint Backlog Items are "owned" by the entire Development Team, even though each one may be done by an individual team member. *
C) Whenever a team member can accommodate more work.
D) During the Daily Scrum.

Poker Planning Deck

Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. It is a variation of the Wideband Delphi method. It is most commonly used in agile software development, in particular the Extreme Programming methodology.

The reason

The reason to use Planning Poker is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants' sizing. Planning Poker should force people to think independently and propose their numbers simultaneously. This is accomplished by requiring that all participants show their card at the same time.

Equipment

Planning Poker is based on a list of features to be delivered and several copies of a deck of numbered cards. The feature list, often a list of user stories, describes some software that needs to be developed.

The cards in the deck have numbers on them. A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions.

 

Planning Poker card deck

The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items.

One commercially-available deck uses the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and optionally a ? (unsure) and a coffee cup (I need a break). Some organizations use standard playing cards of Ace, 2, 3, 5, 8 and King. Where King means: "this item is too big or too complicated to estimate." "Throwing a King" ends discussion of the item for the current sprint.

Optionally, an egg timer can be used to limit time spent in discussion of each item.

Planning Poker is a tool for estimating software development projects. It is a technique that minimizes anchoring by asking each team member to play their estimate card such that it cannot be seen by the other players. After each player has selected a card, all cards are exposed at once.

A study by K. Molokken-Ostvold and N.C. Haugen^[3] found that estimates obtained through the Planning Poker process were less optimistic and more accurate than estimates obtained through mechanical combination of individual estimates for the same tasks.​

Scrum Burndown Charts

Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.
The Scrum books define a sprint burndown chart as a place to see daily progress, and a product burndown chart as where to show monthly (per sprint) progress.

Product Burndown Chart

In Scrum, the product burn-down chart is a "big picture" view of a project's progress. It shows how much work was left to do at the beginning of each sprint. The scope of this chart spans releases; however, a release burn-down chart is limited to a single release.
The following example illustrates a product burn-down chart, for an example (ACME ) product:

For more on product and release burn-down charts, please see:
http://www.mountaingoatsoftware.com/release_burndown​

Release Burndown Chart

In Scrum, the release burndown chart is a "big picture" view of a release's progress. It shows how much work was left to do at the beginning of each sprint comprising a single release. The scope of this chart is a single release; however, a product burndown chart spans all releases.
For more on product and release burndown charts, please see:
http://www.mountaingoatsoftware.com/release_burndown​

Sprint Burndown Chart

A sprint burndown chart (or "sprint burndown graph") depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the product backlog items that achieve the goals of the sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours).
To motivate the team, the sprint burndown chart should be displayed prominently. It also acts as an effective information radiator . A manual alternative to this is a physical task board .
Ideally the chart burns down to zero by the end of the sprint. If the team members are reporting their remaining task hours realistically, the line should bump up and down chaotically. The profile shown below is typical, and demonstrates why the "percentage done" concept of traditional project management breaks down. Assuming we started measuring on July 26, what "percentage done" were we on July 28?