Link to Scrum Guide Link to heading

Waterfall Methodology Link to heading

Get requirements from clients
Get rid of client
PPDIOO
Deliver to client and hope they got what they want

Inflexible/unchangeable once started
Testing phase delays until everything is implemented
Focus on software development

Scrum Master Link to heading

The Scrum Master promotes and supports Scrum to the team, ensures that the team is working well together (remove any impediments) and that the team is moving efficiently toward its goal.

They have authority over the process, but not the people or product.

Product Owner Link to heading

The Product Owner sets the vision and goals of the project. They are responsible for maximising the value of the product based on the work of the Developers.

They interact with clients and stakeholders to understand the product’s needs.

They interact with the Developers to communicate these needs and express them as Product Backlog items.

Developers Link to heading

The Developers are a cross-functional, self-managing group that is responsible for converting Sprint Backlog items into working, releasable code.

They have full control over the work needed to create and release the product, but not over the product itself.

User Story versus Epic Link to heading

A user story is a concise description of a feature to implement told from the user’s perspective.

An epic is a series of related and interdependent stories.

Sprint Link to heading

A Sprint is a container event, as all Scrum Events take place within the duration and context of a Sprint.

Increment Link to heading

The aim of a Sprint is to have the Developers produce an Increment - a piece of working and potentially shippable software based on the team’s Definition of Done and leverage the previous Increments.

Sprint Planning Link to heading

Sprint Planning identify items to deliver in the upcoming Sprint - Sprint Backlog.

Daily Scrum Link to heading

Daily Scrum is a short meeting for the Developers to synch their work, assess progress toward their sprint goal, and plan for the day ahead

Sprint Review Link to heading

Sprint Review is an inspection of the output of the sprint - Increment. It allows the team to demonstrate their progress, showcase the product and get feedback.

Retrospective Link to heading

Retrospective is an event where the Scrum Team inspect itself and create a plan for improvements for the next Sprint.

Product Goal versus Sprint Goal Link to heading

The Product Goal describes the ultimate state of the product, which can serve as a target for the Scrum Team to focus on and plan against.

The Sprint Goal is an objective to provide guidance and focus to the Developers for the upcoming sprint (e.g. offer discounts to multi-buying customers).

Product Backlog versus Sprint Backlog Link to heading

A Product Backlog (determined by PO) is an ordered list of project requirements (PBIs) needed to create the product.

A Sprint Backlog (determined by Developers) is a list of PBIs selected for the Sprint.

The Product Backlog is used to produce the Sprint Backlog. Developers work on Sprint Backlog items through the Sprint, and they deliver them as a Product Increment.

Definition of Done (DoD) versus Acceptance Criteria Link to heading

The definition of done is a list of requirements that must be satisfied for all user stories.

Acceptance criteria are particular to each feature being developed.

Story Point Link to heading

A story point is a unit of effort (not time) that defines the effort involved in, or the complexity of, the task we are estimating.

Baseline Link to heading

The baseline is assigned the lowest story point as it requires the least amount of effort and/or has the least complexity. Then, we can estimate the rest of the items based on this baseline.

Planning Poker Link to heading

Planning Poker is played by gathering the Scrum Team together and giving each developer a deck of cards with our chosen estimation scale (story point)

Minimum Viable Product (MVP) Link to heading

The Minimum Viable Product is a simplified version of our product that only contains features considered sufficient for it to be of value to its users.

Velocity Link to heading

Velocity is a measure of the amount of work a team can complete in a sprint, which is the number of POIs we can turn into an Increment during a Sprint

Burndown Chart Link to heading

A burndown chart visualises how much work has been done and how much work remains to be done.

A vertical axis, denoting the work to be done as story points.
A horizontal axis, representing the remaining time.

Scrum Guide Notes

Table of Contents Link to heading