Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments. That is, when the framework is used properly. Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team\u2019s context.<\/p>\n
Scrum is best suited in the case where a cross-functional team is working in a product development setting where there is a nontrivial amount of work that lends itself to being split into more than one 2 \u2013 4 week iteration.<\/p>\n
Teams following scrum are expected to learn and explore the following values:<\/p>\n
The following principles underpin the empirical nature of scrum:<\/p>\n
The team must work in an environment where everyone is aware of what issues other team members are running into. Teams surface issues within the organization, often ones that have been there for a long time, that get in the way of the team\u2019s success.<\/p>\n
Frequent inspection points are built into the framework to allow the team an opportunity to reflect on how the process is working. These inspection points include the Daily Scrum meeting and the Sprint Review Meeting.<\/p>\n
The team constantly investigates how things are going and revises those items that do not seem to make sense.<\/p>\n
The\u00a0Sprint<\/a>\u00a0is a\u00a0timebox<\/a>\u00a0of one month or less during which the team produces a potentially shippable product Increment. Typical characteristics of Sprints:<\/p>\n A team starts out a Sprint with a discussion to determine which items from the product backlog they will work on during the Sprint. The end result of\u00a0Sprint Planning<\/a>\u00a0is the\u00a0Sprint Backlog<\/a>.<\/p>\n Sprint Planning typically occurs in two parts. In the first part, the\u00a0product owner<\/a>\u00a0and the rest of the team agree on which product backlog items will be included in the Sprint.<\/p>\n In the Second Part of Sprint Planning, the team determines how they will successfully deliver the identified product backlog items as part of the potentially shippable product increment. \u00a0The team may identify specific tasks necessary to make that happen if that is one of their practices. \u00a0The product backlog items identified for delivery and tasks if applicable make up the Sprint Backlog.<\/p>\n Once the team and product owner establish the scope of the Sprint as described by the product backlog items no more items can be added to the Sprint Backlog. This protects the team from scope changes within that Sprint.<\/p>\n The\u00a0Daily Scrum<\/a>\u00a0is a short (usually limited to 15 minutes) discussion where the team coordinates their activities for the following day. The Daily Scrum is not intended to be a status reporting meeting or a problem-solving discussion.<\/p>\n At the end of the Sprint, the entire team (including the product owner) reviews the results of the sprint with stakeholders of the product. The purpose of this discussion is to discuss, demonstrate, and potentially give the stakeholders a chance to use, the increment in order to get feedback. The Sprint Review is not intended to provide a status report. \u00a0Feedback from the sprint review gets placed into the Product Backlog for future consideration.<\/p>\n At the end of the Sprint following the sprint review, the team (including the product owner) should reflect upon how things went during the previous sprint and identify adjustments they could make going forward. The result of this\u00a0retrospective<\/a>\u00a0is at least one action item included on the following Sprint\u2019s Sprint Backlog.<\/p>\n The\u00a0product backlog<\/a> is an ordered list of all the possible changes that could be made to the product. \u00a0Items on the product backlog are options, not commitments in that just because they exist on the Product Backlog does not guarantee they will be delivered. The Product Owner\u00a0maintains the product backlog<\/a>\u00a0on an ongoing basis including its content, availability, and ordering.<\/p>\n The Sprint Backlog is the collection of product backlog items selected for delivery in the Sprint, and if the team identifies tasks, the tasks necessary to deliver those product backlog items and achieve the Sprint Goal.<\/p>\n The increment is the collection of the Product Backlog Items that meet the team\u2019s Definition of Done by the end of the Sprint. \u00a0The Product Owner may decide to release the increment or build upon it in future Sprints.<\/p>\n The\u00a0definition of done<\/a>\u00a0is a team\u2019s shared agreement on the criteria that a Product Backlog Item must meet before it is considered done.<\/p>\n The\u00a0product owner<\/a> is a role team responsible for managing the product backlog in order to achieve the desired outcome that the team seeks to accomplish. The product owner role exists in Scrum to address challenges that product development teams had with multiple, conflicting directions or no direction at all with respect to what to build.<\/p>\n The\u00a0scrum master<\/a> is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use. The name was initially intended to indicate someone who is an expert at Scrum and can therefore coach others. The role does not generally have any actual authority. People filling this role have to lead from a position of influence, often taking a servant-leadership stance.<\/p>\n The development team<\/a> consists of the people who deliver the product increment inside a Sprint. The main responsibility of the development team is to deliver the increment that delivers value to every Sprint. How the work is divided up to do that is left up to the team to determine based on the conditions at that time.<\/p>\n Scrum is a framework that allows development teams the flexibility to respond to changing situations. This framework has sufficient control points in place to ensure the team does not stray from the desired outcome, and that issues can be identified and resolved and process adjustments made while the effort is still underway.<\/p>\n The Scrum Lifecycle starts with a prioritized backlog but does not provide any guidance as to how that backlog is developed or prioritized.<\/p>\n The Scrum Lifecycle consists of a series of Sprints, where the end result is a potentially shippable product increment. Inside these sprints, all of the activities necessary for the development of the product occur on a small subset of the overall product. \u00a0Below is a description of the key steps in the Scrum Lifecycle:<\/p>\n 1986: Takeuchi and Nonaka publish their article \u201dThe New New Product Development Game<\/a>\u201d in Harvard Business Review. The article describes a rugby approach where \u201cthe product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.\u201d This article is often cited as the inspiration for the Scrum framework.<\/p>\n 1993: Jeff Sutherland invents Scrum as a process at Easel Corporation<\/p>\n 1995: Ken Schwaber and Jeff Sutherland co-present Scrum at the OOPSLA Conference<\/p>\n Scrum\u2019s primary contribution to the software development world is a simple, but effective approach to managing the work of a small collaborative team involved in product development. It provides a framework and set of simple rules that allow an appropriate amount of planning, control over the work, risk identification and mitigation, and issue identification and resolution.<\/p>\n Scrum Guide<\/a><\/p>\n Agile Software Development with Scrum<\/a>\u00a0by Ken Schwaber and Mike Beedle<\/p>\n Agile Project Management with Scrum<\/a>\u00a0by Ken Schwaber<\/p>\n\n
Sprint Planning<\/h4>\n
Daily Scrum<\/h4>\n
Sprint Review<\/h4>\n
Sprint Retrospective<\/h4>\n
Artifacts<\/h3>\n
Product Backlog<\/h4>\n
Sprint Backlog<\/h4>\n
Increment
\n<\/strong><\/h4>\nDefinition of Done<\/h4>\n
\nRoles<\/h2>\n
The Product Owner<\/h4>\n
The Scrum Master<\/h4>\n
The Development Team<\/h4>\n
\nLifecycle<\/h2>\n
\n
\nOrigins<\/h2>\n
\nPrimary Contributions<\/h2>\n
\nFurther Reading<\/h2>\n