This article provides a brief overview of key Scrum terminologies and explains how Scrum, as a framework operating within Agile principles, implements them.

In our fast-paced world, technology and innovations are moving faster than ever before and let’s face it, change is inevitable. In order to keep up we needed to get equipped with better practices, tools and technologies and therefore agile terminology was invented.

It all started with one question: “how to speed up development times in order to bring new software to the market faster?” and therefore a group of 17 developers came up with a list of 4 foundational values that is known as Agile Manifesto and 12 principles that is leading the agile development efforts. If you wish to learn more about them, visit The Agile Manifesto website for further details.

What is agile?

Agile is a set of methods and practices that focuses on iterative development to build shippable products faster and cope with changes quickly, effectively and efficiently. The need for change, competition, flexibility and value is the reason behind the popularity of agile methodologies. There are various advantages for becoming agile, some of them are listed below:

Improved collaboration and interaction between the project team and project deliverables.
Stakeholders have visibility of each phase of the project.
Project follows a predefined schedule and has predictable shipping time and costs associated with it.
Delivering projects on iterations/cycles, faster without compromising quality.
The project is broken down and therefore high-quality development, testing and collaboration is ensured throughout the project life cycle.
The product requirements can be refined and re-prioritized.
The primary focus would be on customers and shipping quality products.

There are many agile frameworks in the market. To name a few; Scrum, Kanban, XP, Lean and Crystal are the most popular and widely used agile methodologies in the market with Scrum leading the pack.

What is Scrum?

Scrum is a framework for creating, delivering, and maintaining products in a complex environment. It was originally developed for software development, but it has now been used in various industries such as research, sales, marketing, and advanced technologies. Scrum enables teams to work together, learn from experiences, self-organize, reflect and improve. Scrum helps deliver a product in iterations or chunks which are called sprints.

Some of the advantages of using Scrum are:

Teams can provide project deliverables iteratively and in an efficient manner.
Time and money are used efficiently.
Projects are divided into smaller units called sprints (iterations). Sprint is a time-boxed iteration taking as a subset of product backlog and reviewed on daily basis.
Works best for fast moving projects, while ensuring effectiveness and defect free.
Scrum meetings provide the team with great visibility.
It constantly involves feedback from clients and stakeholders.
Making changes based on feedback is very easy.
Individual efforts of the team members are given focus.

Scrum values commitment, focus, openness, respect and courage which are the characteristics of a great team.

Scrum team structure

A Scrum team should consist of less than 9 people and more than 3 with an ideal size of 7. A scrum team should be cross-functional which means that the team should be equipped with the skills and technical knowledge that are required to complete the project. A Scrum team consists of 3 roles that involve:

Scrum Master: Helps teams learn and apply Scrum to obtain business values, helps remove impediments (barriers, anything that stops the work or a bottleneck), protects the team from interference and helps the team to adopt agile practices. The Scrum master assists the development team and product owner working to maximize ROI and empowers the development team. A scrum master is a servant leader, facilitator of scrum events, impediment remover and a process coach, however, a scrum master is NOT: a line manager, task master, technical or design authority and or a decision maker. A scrum master influences without authority.
Product Owner: Responsible for maximizing the return on investment (ROI) by determining the product features and prioritizing them in into a list. The product owner decides what needs to be focused on for the next iteration (sprint) and constantly reprioritizes and refines the backlog. A product owner defines project vision, requirements and priorities, makes decisions during sprint planning and acts as the voice of the customer.
Scrum Team: A collection of individuals that work together to deliver the requirements of the stakeholder. They should have a clear understanding of deliverables and what needs to be achieved. The team consists of 3 to 9 self-organizing members that should independently self-organize and plan to meet the product owner’s goals. Desirable attributes of a scrum team are being small and nimble (no less than 3 and no more than 9), self-sufficient and cross functional, autonomous and self-organizing.

Scrum Artifacts

Scrum artifacts are components of the Scrum process that can improve transparency and understanding of the work. There are three main and compulsory artifacts in Scrum;

Product backlog: It is where you list all the requirements of the project in form of a user story or a requirement. A product backlog is a list of new features, changes to existing features, bug fixes, changes to infrastructure, non-functional requirements and several other activities that a team needs to deliver to ensure a particular outcome. Product backlog can keep changing throughout the project.
Sprint Backlog: It is a subset of product backlog that contains tasks that the team aims to complete to satisfy the sprint goal. Basically, some specific features or requirements are selected from a product backlog and transferred to sprint backlog to be delivered in an iteration. The sprint backlog is ideally selected by the team in a sprint planning session. Objective is decided for the sprint as an outcome of negotiations between the product owner and the team.
Product Increment: The combination of all product backlog tasks completed in a sprint and the value increments of previous sprints. The outcome should be in usable condition, even if the product owner doesn’t decide to deploy it. There is a difference between release and deployment; release makes a product usable and deployment makes it available to users. An increment refers to inspectable and usable work done at the end of a sprint. It also represents a step towards the overall goal or vision of the project.

Scrum Lifecycle

A scrum-based project follows the specific steps shown in image above and hereby, I will explain each of the items in the process:

Product backlog: The first step of the Scrum framework is a set up list of tasks to successfully achieve the goal of the stakeholder. The product backlog is groomed, prioritized and re-prioritized during the life cycle of the project.
Sprint planning: The team determines the tasks from the product catalog they will work on and aim to deliver during the sprint. Ideally, a planning session should be 2 hours long each week. For example, if a sprint is 4 weeks long the meeting should be scheduled for 8 hours.
Sprint backlog: The tasks discussed during sprint planning and then added to sprint backlog.
Scrum Team: Scrum team (usually 5 to 9 members) work on the tasks in the sprint backlog.
Daily scrum: A 15 min long event where the team synchronizes activities and plans for what they aim to achieve in the next 24 hours.
Sprint Review: Done once the sprint is complete. It involves the team, scrum master, product owner and stakeholders. In this event the team demonstrates the completed work and the client provides feedback. Product owner also presents that product backlog’s top to the stakeholders, to get feedback for upcoming sprints and about things related to the backlog. At this event all the shipped features are checked against the definition of done defined at the sprint planning session and will be marked as accepted or rejected. Sprint review sessions should be 1 hour long for each week, which means for a 4 weeks sprint, the sprint review session is 4 hours.
Sprint Retrospective: At this event, the team, scrum master and optionally the product owner reflect on what went well? What would the team do differently? Past mistakes, potential issues and new ways to handle them are also discussed during this meeting. Data from this meeting is recorded as lessons learned for the new sprint.
Increment: As a result, the iteration is incremented and workable output is given to the stakeholder.

What is a Sprint?

Sprint is synonymous with iteration. Sprint refers to short periods of time during which a Scrum team aims to get a given amount of work done and ideally it should be 1 to 4 weeks long. Sprints help teams deliver a working product in a frequent manner. Factors affecting duration of a scrum are stability of the backlog and cost of iterating. Each sprint should have a goal; Goal of a sprint is a working software; the end product should be near releasable or potentially shippable. Sprint duration and deliverables do not change once the team has committed, it is either delivered or cancelled in extreme circumstances which is decided by product owner. Sprint starts with the sprint planning session and ends with sprint review and retrospective.

Sprint Planning: Sprint planning helps decide the tasks that the team has committed to in order to achieve the Sprint goal. The team should make an informed commitment about what they will deliver. It is conducted right at the beginning of the sprint and is attended by the team, product owner and scrum master. There are two possible approaches to decide what is delivered by the end of the sprint, it is either based on team commitment or velocity of the team. In this meeting the team buy-in is crucial and the goal should be clearly understood by the whole team. At this meeting the team also decide on what does Done means, they need to articulate a “Definition of Done” which varies from team to team. For example, a team may decide on definition of done as; 1) The feature is developed. 2) The feature is tested. 3) Features pass all unit testing criteria. 4) The feature is documented. However, each team may define different definitions based on their perspectives and type of project. Additionally, the goal should be realistic, achievable and the entire team should agree upon it.
Daily Scrum/Stand-up Meetings: Every day during the sprint, the team should have a 15-minute meeting which is known as daily scrum or stand-up meetings. Stand-up meetings are a meeting of the team, by the team and for the team. The entire team should attend this meeting; however, the attendance of the product owner is considered optional. Each team member answers 3 questions during this meeting; What was done yesterday? What is considered to be done today? and are there blocking issues? and the visual board is updated accordingly. Scrum master takes notes of any blocking issues and focuses on resolving them.
Sprint Review: Once the sprint is completed, a sprint review ceremony or session takes place. Sprint reviews are basically a demonstration of the deliverables of the sprint and getting feedback from the client and the team. The meeting is attended by the entire team including product owner and optionally other project stakeholders. The purpose of the meeting is to showcase achievements, generate feedback and decide about the release. The product owner is the most active person in this meeting in which he/she will check all the delivered sprint backlogs and check against definition of done.
Sprint Retrospective: Sprint retrospective is a continuous improvement mechanism in a Scrum team. It helps discuss what is working, what is not and what could be better. This meeting is attended by the scrum master and the team. Product owners may also join the meeting; however, it is considered optional. Scrum retrospective has many benefits in which the team can understand their velocity as well as learn from their mistakes. It makes issues visible, helps the team to come up with opportunities for improvement and gives the team ownership of the action.

Scrum Board

Scrum board is a physical or virtual tool that helps the team to visualize items in the sprint backlog. It shows all action items during the daily scrum, and helps the team to focus. The board should be presented in a place that is accessible by the whole team, mainly in the form of a whiteboard or a software tool. The scrum board is divided into many slots: To do, in progress and done. When the new sprints are started the existing board is reset and a new Scrum board is created. Jira and Trello are some of the most widely used tools instead of physical boards.

User Stories (a deeper dive)

A user story describes anything of value that the team can produce for the customer. Customer requirements may be designed in the form of a user story and recorded in backlog. A user story can be a use case which describes what a user wants to do and how the system should support the user. It also can be a functional requirement, a technical task or even a bug fix. A good user story should be independent, negotiable, valuable, estimable, small and testable.
A user story is formed in the following format using physical or virtual cards, for example, you can write a user story as follows: As a system user, I want a login screen so that I can login to the system to perform updates.
If there are multiple similar stories they can be grouped in the form of an epic or higher-level story. Stories can also be divided into children’s stories or tasks if they are too big and cannot be done in a specific sprint.

Multiple epics can also be joined together to form a theme. Themes and epics cannot be completed in one sprint so they are broken into more user stories and subsequently a group of related tasks. Epics are then delivered in final releases. But even small user stories from different epics can have something in common. Such a group of user stories is called a theme.

It is worth mentioning that a sprint may contain multiple user stories, but one user story cannot be completed in multiple sprints, therefore, if a user story cannot be done in one sprint you must break them down. Since the product owner is the customer voice in the team, deciding about user stories is the responsibility of the product owner and the team.

A user story card may contain a title, order/story sequence, user story and story point. Additionally, it is also encouraged to have further description about the story, value point, story type, responsible person, sprint and any further supporting information or document.

Each user may have an estimation that is either based on points or hours. Currently, story points are more popular among the Scrum teams. There are various ways to calculate story points, however, Fibonacci sequences are more popular.

Story Points and Estimation

Estimating is a very difficult task; therefore, the Scrum team works with the product owner in order to make a better estimate of the items in the backlog. Being accurate is neither possible nor advisable and in Scrum the only estimate that matters is the one given by the team. Scrum doesn’t make estimations any easier, however, it exposes bad estimates sooner which helps the team to understand their mistakes.

A story point is an absolute measure of size and is an analogous estimate technique. The points given to a story represent the entire work including any issues, however, buffers are not considered in a story point.

Scrum teams mainly use the Fibonacci sequence as story points which is a series of numbers in which each number is the sum of the two that precede it; 0, 1, 1, 2, 3, 5, 8, 13, 21, … however, they are modified with another version to make it easier and readable.
Modified Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Please note that using user stories, Fibonacci sequence and many other practices are not a mandatory requirement of agile, as described previously you can use ideal time for estimation instead and you can adopt whatever works for you, however, these are just practices that makes your life easier.

As best practice the team establishes benchmarks and compares stories to the benchmark in order to find out the best possible estimate for a task. Ideally, you should have more than one benchmark like Small: 1, Medium: 5 and Large: 13. Benchmark works because human beings are better at comparisons than absolutes.

Planning Poker

Planning poker is a quick and fun team approach to estimation. It is a popular exercise among the Scrum teams. It starts with selecting the team for estimation and providing each with a deck of cards and numbers printed on them. Product owner reads and quickly explains a story followed by the team discussing the story and each member picks the card that matches his or her estimate. Each one chooses independently and does not display to others. Once the Scrum master prompts, everybody’s estimates will be revealed. It is expected that the numbers will vary; discuss the variations and choose cards again and repeat until estimates converge or the team agrees on an estimate.

Conclusion

In conclusion, Scrum is undoubtedly Agile’s best framework so far and practitioners have come across many great additions, best practices and tools over time. Adopting Scrum will help teams collaborate and build tools faster with a mentality to ship working products at the end of each sprint. Scrum brings the decision making and authority from managers back to the teams and gives them the opportunity to learn from their mistakes.

What are You Looking For?

How to practice Scrum in your projects?