© 2019 by DevelopAgile.com 🐿️

Website developed through ongoing iterative and agile development.

PSST! Need some help?

You can search for terms in the Search bar above! ;)

The Agile Dictionary

 

Scrum Boards are borrowed from the Kanban framework. It refers to a physical (white board) or virtual board divided into columns that show every flow of the production. The board usually contains at least 3 columns, To Do, In Progress, and Done (columns like code review or testing can be added to suit the business needs). The difference between Kanban Boards and Scrum Boards is essentially the presence of sprints in Scrum. For Scrum Boards, only the user stories selected for the sprint will be displayed on the board and the goal at the end of the sprint is to have all the sprint’s user stories in the Done column. The board is displayed in the Team room for anyone to see the project work and its status.

Scrum Board

The Scrum Master is the person responsible for ensuring the Scrum Team understands, works and lives by the Agile values and principles and follows the agreed upon processes and pratices. The Scrum Master is a communication facilitator who manages the process for how information is exchanged. Although the title sounds powerful, the person is not the project leader nor is held accountable for the outcomes of the project and is not involved in the decision-making process. As per the official Scrum Guide, the Scrum Master is a servant-leader for the Scrum Team.

Scrum Master

Spikes or Research Spikes come from the Extreme Programming (XP) Agile Framework and refers to a time of exploration. This occurs when the Team has trouble to properly estimate a user story and is missing too much information. Instead of including the user story into the sprint, the research on the user story will replace it to figure out the nature of the new feature being built. Spikes are considered very much like user stories, will be time-boxed with a maximum duration as the sprint with the goal of getting the Spike in the Done column at the end of the sprint. It is basically like taking a minute to think about the best way to work instead of going straight into the pile of work. Spikes are investments made to gain advance knowledge on the user story and make it estimable and therefore schedulable.
 

Spike

Scrum determines fixed length iterations in which new feature(s) will be developed. These iterations are called Sprints that typically last between 1 and 4 weeks. The goal of each sprint is to deliver a shippable product, refering as the Agile principle of working software. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprint

The Sprint Backlog also known as Sprint Product Backlog is a subset of the Product Backlog that contains only the user stories to complete for that particular sprint. These user stories are the pulled from the top of the Product Backlog during the Sprint planning.

Sprint Backlog

The Sprint Goal is crafted by the Product Owner and is further discussed with the Development Team. The Sprint Goal defines the main objective that should be achieved during the Sprint and provides a clear statement about what has to be delivered and why.

Sprint Goal

The Sprint Planning (also know as WHAT-Meeting or kick-off meeting) takes place at the very beginning of each Sprint. In this meeting including the entire Scrum Team, the user stories to include in the upcoming sprint are discussed. The purpose of the sprint planning is to determine and define what can be delivered in the upcoming sprint and how it will be achieved. We usually count 2 hours of meeting per week of sprint.

Sprint Planning

The Sprint Retrospective (also known as Iteration Retrospective) occurs at the end of each sprint after the sprint review and before the start of the next sprint with the sprint planning. The entire Team should participate to this continuous improvement opportunity. The Team should discuss what happened during the sprint and ask themselves 3 questions:

  • What worked well?

  • What did not work well?

  • What actions can we take to improve our process going forward?

Sprint Retrospective

The Sprint Review is an informal meeting including the whole Scrum Team taking place at the end of each sprint. The purpose of the meeting is to present what has been accomplished during the sprint, often including a demo of the new features. It is not a status update nor a sprint retrospective and the goal is really to demonstrate the actual increment achieved during the sprint.

Sprint Review

Using the Scrum framework, there is a daily meeting with the whole Team including the Product Owner, the Development Team, the Scrummaster as well as customer and external stakholders.

It is essential that all the involved members of the Scrum Team are present for this meeting. It should last no longer than 15 minutes and it is held as a stand-up meeting, making people uncomfortable on purpose so it does not last too long.

Each Team member should answer 3 questions:

  • What have I done since the last Daily Scrum

  • What will I do until the next Daily Scrum?

  • Which impediments are in my way?

Stand-Up Meeting

Related Terms:

Daily Scrum

Story Mapping is a customer-centric method for generating and arranging user stories. User stories are generated through an anlaysis at the user’s journey throughout the product. This will give real user stories that users can expect and recognize value in. The mapping will be arranged on a horizontal axis displaying the fundamental steps in the user’s journey (known as workflow or usage sequence) in the chronological order and a vertical axis listing the user stories by priority order.

Story Mapping

Before a user story is ready to be added to a sprint, it has to match certain criteria. User Stories usually start as big stories which are not well-defined and probably would fit into a single sprint, therefore, they have to be decomposed into smaller ones, that’s story splitting. User stories should always check the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) criteria.

Story Splitting

Sustainable development is one of the Agile’s Principles which states that the pace should be kept indefinitely. While definitions may vary, sustainability means two main things:

  1. Team should continue to release new feature that will bring value

Most of the time, the product will continue to evolve with new business needs, new technology and it is supposed to last for decades until it reaches the point of an empty Product Backlog.

  1. Team and Team members shouldn’t be overused

People should be careful with long work hours, overtime or working on the weekends. It is common in the industry to make a bit of overtime because of the deadlines but it shouldn’t be repeated too much.

Sustainable Pace