The sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. The Development Team should keep in mind the velocity of its previous Sprints (total story points completed from each of the last sprint's stories) when selecting stories/features for the new sprint, and use this number as a guide line of how much "effort" they can complete.

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach". Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

The stories/features are broken down into tasks by the Development Team, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the Development Team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed during the daily scrum, according to the set priority and the Development Team member skills. This promotes self-organization of the Development Team, and developer buy-in.

This is the process of creating stories, decomposing stories into smaller ones when they are too large, refining the acceptance criteria for individual stories, prioritizing stories on the product backlog and sizing the existing stories in the product backlog using effort/points. During each sprint the team should spend time doing product backlog refinement to keep a pool of stories ready for the next sprint. 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. Though everything can be done in a single meeting, these are commonly broken into two types of meetings for efficiency: The refinement meeting, where the product owner and stakeholders create and refine stories on the product backlog. The planning poker meeting, where the team sizes the stories on the product backlog to make them ready for the next sprint.

A feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. The structure of a story is: "As a I want to so that " This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand. Example: As a wiki user I want a tools menu on the edit screen so that I can easily apply font formatting. A story is an independent, negotiable, valuable, estimable, small, testable requirement ("INVEST"). Despite being independent, i.e., they have no direct dependencies with other requirements, stories may be clustered into epics when represented on a product roadmap or further down in the backlog. [...] An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break down into component stories, which should be done before bringing it into a sprint so to reduce uncertainty. Epics can also be used at both program and project level.

Scrum was first defined as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach" in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the "New New Product Development Game".[2] Takeuchi and Nonaka later argued in "The Knowledge Creating Company"[3] that it is a form of "organizational knowledge creation, [...] especially good at bringing about innovation continuously, incrementally and spirally".

The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries.[4] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team "tries to go the distance as a unit, passing the ball back and forth".

The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like "to do", "in progress" and "done". Once a Sprint's Product Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of functionality is selected for the next Sprint.

At the beginning of the sprint cycle (every 7–30 days), a "Sprint planning meeting" is held: Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team Identify and communicate how much of the work is likely to be done during the current sprint Eight-hour time limit (1st four hours) Entire team:[13] dialog for prioritizing the Product Backlog (2nd four hours) Development Team:[14] hashing out a plan for the Sprint, resulting in the Sprint Backlog

The product backlog is an ordered list of "requirements" that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc. - whatever needs to be done in order to successfully deliver a working software system. The items are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format (See terminology below). The product backlog is the "What" that will be built, sorted in the relative order in which it should be built. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team. The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonacci sequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items. For example, if the "add spellcheck" and "add table support" features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher. The Product Backlog and business value of each listed item is the responsibility of the Product Owner. The estimated effort to complete each backlog item is, however, determined by the Development Team.