Scrum is a lightweight agile process framework used primarily for managing software development.
Scrum processes are cyclical, repeating every few weeks. Product Owners provide requirements, in the form of Stories (short narrative descriptions). The Team of developers and QA engineers implements the Stories in a Sprint of 2—4 weeks in length. During the Sprint, Team members work with Product Owners to refine and clarify requirements, to ensure proper implementation. Final requirements are defined by test cases created by QA engineers, and are used to validate each story to confirm that it is complete.
Stories are implemented in rank order, one at a time, to ensure that highest-priority requirements are implemented first. This serialization of feature development ensures that some useful features will be completed even if less work can be accomplished during a Sprint than expected.
Scrum is applicable to any project with aggressive deadlines, complex requirements and a degree of uniqueness.
Scrum is based on a set of fundamental values. The values provide a code of behaviour, or ethics, for Scrum Teams – some rules of conduct for teams to embody and live by as they work with Scrum.
Source:techtarget.com
Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
People personally commit to achieving the goals of the Scrum Team.
Scrum Team members have the courage to do the right thing and work on tough problems.
Scrum Team members respect each other to be capable, independent people.
This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation.
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’s success.
Frequent inspection points 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.
The team constantly investigates how things are going and revises those items that do not seem to make sense.
This principle increases the level of independence of the whole team and also helps to assess their performance.
Awareness, clarity, and distribution become particularly important while working on each release.
In Scrum, tasks are constantly prioritized based on their value and importance for the end-users and the company to determine the order in which these tasks need to be completed.
It implies allocating and scheduling certain amounts of time for certain activities. In Scrum, work is done in short release cycles called “sprints” (usually 2-4 weeks). Tasks are determined during sprint planning (usually around 1-2 hours), monitored and discussed at daily meetings (usually around 15 minutes), evaluated during sprint reviews (usually around 1-2 hours), etc.
As the project requirements in Scrum are constantly being adjusted and revised, software development activities in this framework are also repeated, revisited, and reworked to create the best product.
Source: brainhub.eu
The Sprint is a timebox of one month or less during which the team produces a potentially shippable product Increment. Typical characteristics of Sprints:
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 Sprint Planning is the Sprint Backlog.
Sprint Planning typically occurs in two parts. In the first part, the product owner and the rest of the team agree on which product backlog items will be included in the Sprint.
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. The team may identify specific tasks necessary to make that happen if that is one of their practices. The product backlog items identified for delivery and tasks if applicable, makes up the Sprint Backlog.
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.
The Daily Scrum is 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.
At the end of the Sprint, the entire team (including 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. Feedback from the sprint review gets placed into the Product Backlog for future consideration.
At the end of the Sprint following the sprint review the team (including product owner) should reflect upon how things went during the previous sprint and identify adjustments they could make going forward. The result of this retrospective is at least one action item included on the following Sprint’s Sprint Backlog.
Source: usefyi.com/
The product backlog is an ordered list of all the possible changes that could be made to the product. Items 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 maintains the product backlog on an ongoing basis including its content, availability, and ordering.
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.
The increment is the collection of the Product Backlog Items that meet the team’s Definition of Done by the end of the Sprint. The Product Owner may decide to release the increment or build upon it in future Sprints.
The definition of done is a team’s shared agreement on the criteria that a Product Backlog Item must meet before it is considered done.
Source: scrum.org
The product owner 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 direction, or no direction at all with respect to what to build.
The scrum master 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.
The development team 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 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.
Scrum lifecycle is a number of consecutive steps and iterative stages that should be performed during the realization of any Scrum project. The iterative approach is the main principle of the Scrum lifecycle. The work on a Scrum project is subdivided into segments called Sprints. The project develops from one sprint to another until the final product is ready. Each sprint is subdivided into several consecutive stages that it must pass from the beginning till the end. Scrum methodology also includes more specialized lifecycles like the testing life cycle and the defect life cycle.