Scrum Glossary

Agile Manifesto

In 2001, a group of software developers (while on a skiing vacation) published a manifesto that has since been considered the heart of all Agile methods. Scrum is a way of realizing this manifesto.

The complete Agile manifesto is as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions Over processes and tools

Working software Over comprehensive documentation

Customer collaboration Over contract negotiation

Responding to change Over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Daily Scrum

The Daily Scrum is normally a 15 minute meeting for the Development Team to inspect the work since the last meeting, and synchronize their work and plan for the next 24 hours. It must be held on a daily basis.

During the Daily Scrum, each member of the Development Team should answer these three questions:

  1. What has been accomplished since the last meeting?
  2. What will be done before the next meeting?
  3. What obstacles are in the way?

The Daily Scrum meeting should be held at the same time and place throughout the Sprint, to minimize the complexity. It is just for the Development Team; it is not a status meeting for all the stakeholders.

The Development Team should also monitor Sprint progress each day and therefore it is a good idea for the Sprint board (wall chart) to be visible during the Daily Scrum meeting. They can use a burn-down chart to track their remaining work and check to see if they are going to complete all items before the end of the Sprint.

Definition of Done

There should be a shared understanding of what it means for a piece of work to be “Done”. This definition of “Done” must be discussed and agreed upon by the Scrum Team at the beginning of the project so that future Increments would be releasable.

When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of “Done” for all teams, because they might be working on items of different natures. In such a case, each Scrum Team will define its own definition of “Done” and delivers its items based on that definition. However, the integration of those definitions of “Done” should be capable of creating a potentially releasable Increment in the project level.

Development Team

The “Development Team” is one of the three roles defined in Scrum. Members of the Development Team are application area experts that are responsible for delivering backlog items, and managing their own efforts.

They should be cross-functional; being capable of doing the A to Z of the creation of each Product Backlog item. They should be self-organized; find their own way instead of receiving orders. They should be aligned with the goal of the project instead of working blindly. A task might be assigned to a single member throughout the Sprint, but the whole Development Team will be responsible and accountable for that task; no individual owns any task.

The Development Team delivers the final product of the project in step by step Increments, as defined in the Product Backlog. They always work in a product-based way.

It is highly recommended for members of the Development Team to work full-time in a single project, to stay focused and agile. The composition of the Development Team should not change so often. If there is a need to change team members, then this change should not happen during a Sprint. There will be a short-term decrease in productivity when the composition of the team changes.

Scrum is mostly effective when there are 3 to 9 Development Team members. For large projects, we can use a scaled model with multiple Scrum Teams. However, the use of multiple teams is not common in Scrum but you need to be aware of this.


An Increment is a sum of all completed Product Backlog items at the end of a Sprint. Each Increment must be “Done”, and must be releasable. The Product Owner may or may not release a certain Increment, but it should be releasable (shippable).
The next figure shows how the number of stories in the Product Backlog decreases Sprint by Sprint, as the number of features in the Increments increases.

Note that the Increment concept is cumulative: each Increment also contains the features of the previous ones.

Monitoring Progress Toward a Goal

The Product Owner is responsible to monitor the progress of the whole project toward its goal. This should be done at least once per Sprint Review. The Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints, and forecasts the completion date of the project. All stakeholders should have access to this information.

The project burn-down chart shows the amount of remaining work, instead of the amount of completed work; therefore, the line for actual performance goes downward as we proceed and the faster it goes down, the happier we will be!

Monitoring Sprint Progress

Besides the monitoring done for the whole project, we should also monitor the progress of each single Sprint throughout its life. This is the responsibility of the Development Team and should be done at least once per Daily Scrum. This information is used to calculate the likelihood of achieving the Sprint Goal and completing all items of the Sprint Backlog.

The Sprint progress information can be represented by a burn-down chart, and this chart can be a part of the Sprint board, where everyone can see.

Product Backlog

The Product Backlog is an ordered list of everything that might be needed in the final product of the project, in other words parts of the expected final product (a wish list). All items are described in simple business language (non-technical) and all of them are presentable to every stakeholder. Every requirement and every change in the project will be reflected in the Product Backlog.
The Product Backlog is dynamically changing and improving; it is never complete. We do not wait until the Product Backlog is complete to start delivering the items; the first Sprint can be started as soon as the Product Backlog has a sufficient number of stories defined.

The Product Owner sets a number of factors to determine the value of each item for the business. Return on investment is usually one of the factors. All these factors will be summarized into one value (importance) and this is shown with each item.

The Product Backlog items will then be ordered based on their value, in a way that the higher an item is, the sooner it will be delivered by the Development Team. As the items located at top of the Product Backlog will be delivered sooner, they will also be more detailed and clear compared to the lower items.

Each Product Backlog item also has a work estimate. These estimates are solely done by the Development Team, and are used in comparison to the capacity of the Development Team in a single Sprint, to determine the number of items that will be selected for that certain Sprint. Additional information might be added to each item to help the Scrum Team take control.

Product Backlog Grooming

Besides the time boxed event discussed before, there is also an ongoing activity in Scrum projects called Product Backlog grooming. It is the act of reviewing and revising Product Backlog items, which typically involves adding detail, estimates, and order to them. The Product Owner is responsible for ordering (prioritizing) the items and the Development Team is responsible for estimating those items.

The main difference between this activity and the five Scrum events is that Scrum events are all time-boxed, but grooming is an ongoing activity that happens throughout the Sprint. This activity should not consume more than 10% of the time of the Development Team.

Product Owner

The Product Owner is one of the three roles defined in Scrum.

Each project needs a business oriented person, aimed at maximizing the value of the product and the work of the Development Team. In Scrum, this person is called Product Owner. Product Owners, like the two other roles, are from the performing organization, rather than from the client.

This role belongs to one person. There can be a committee to handle the responsibilities of this role, but in such a case, there should be one person representing this committee and we call this one person the Product Owner.

They do not need to have application area knowledge of the project; they are focused on the business aspect. In software development projects for example, Product Owners do not need to be developers themselves, they just need to know a little about development, but a lot about how the business operates.

The Product Owner is responsible for the Product Backlog. The Product Backlog is a prioritized list of items (aka stories or user stories) that the client expects from the project; this is the main planning tool in Scrum. It is also the responsibility of the Product Owner to make sure that each item (user story) is easy to understand for the Scrum Team, and other stakeholders.

Product Owners should communicate effectively with the customer (the inevitable success factor in every project management method), and use the information to keep the Product Backlog updated with all the changes. They also measure the performance of the project, forecast the completion date, and make this information transparent to all stakeholders.

Product Owners understand the business, so they can rank each Product Backlog item based on its return on investment as well as any other factor they find suitable for the business point of view of the project. The items will be sorted based on their value, so the higher they are on the list, the sooner they will be developed by the Development Team.

The entire organization must respect the Product Owner decisions for the project to be successful. No one, even the CEO, should allow themselves to try to override those decisions, and no one should tell the Development Team what item to deliver, except for the Product Owner who sets and orders the items. A Product Owner’s decisions might be influenced by others, but he/she must have the final say.

A Product Owner might delegate some of his/her responsibilities (such as preparing the list of items for the Product Backlog) to the Development Team, but stays accountable for them.

Project Manager

Scrum projects do not have a role called “project manager”.

Some people consider the Scrum Masters to be the equivalent to traditional project managers; but it is not true, because the Scrum Master responsibilities are very different than a traditional project manager.

So, a better question to ask is: what happens to project management?

The project management responsibilities are distributed among the three roles of Scrum and there is no centralized project management in Scrum.

Scrum Master

The Scrum Master is one of the three roles defined in Scrum.

Scrum Masters are those who fully understand Scrum, and help the Scrum Team by coaching them, and ensuring that all Scrum processes are implemented correctly. The Scrum Master is a management position, which manages the Scrum process, rather than the Scrum Team. He/she is a servant-leader for the Scrum Team.

Besides ensuring that the Development Team understands and uses Scrum correctly, the Scrum Master also tries to remove impediments to the Development Team, facilitates their events, and trains and coaches them.

The Scrum Masters help the Product Owners too, by helping or consulting them on finding techniques, communicating information, and facilitating related events.

The responsibilities of the Scrum Masters are not limited to the Scrum Team. They should also help those outside the Scrum Team understand the appropriate interactions with the Scrum Team to maximize the value created by the Scrum Team. The Scrum Master usually leads the organization in its effort to adopt Scrum.

It is possible for a single person to be both Scrum Master, and a member of the Development Team, although this is not recommended. Being a Scrum Master of a project might not occupy 100% of the time of a person; in this case, the best solution is to assign that same person as the Scrum Master in more than one project, rather than making them a member of the Development Team.

Scrum Team

There are three roles in a Scrum project; no less, and no more. We are not allowed to define any other roles, because it is harmful to the unity of the team, and it is not compatible with the philosophy of Scrum.

A Scrum Team consists of the following three roles:

  • Scrum Master
  • Product Owner
  • Development Team

The term “Scrum Team” refers to all the project team members: everyone internal to the project. Scrum Team members usually have only one of the three standard roles of Scrum: Product Owner, Scrum Master, or Development Team member. It is possible for a single person to be assigned to more than one of the standard roles, but it is not recommended.

The Scrum Team is a part of the performing organization (the company which executes the project either for itself or as a contractor for an external customer).

Other persons can also be involved in the project but they are not considered internal to the project and Scrum theory does not have much to say about them. They should have a certain set of behaviors though (e.g. respect how a Scrum project works), to make it possible for a Scrum project to succeed.

The customer should understand and adopt the Scrum framework too, as the relation between the customer and the performing organization and the way we deliver the project completely changes when we switch to the Scrum framework.

The Scrum Team has two essential characteristics:

  • Self-organized: The Scrum Team manages its own efforts rather than being managed or directed by others. In traditional methods, management efforts are separated and centralized; a subset of the project team is responsible for project management and others are only responsible for specialist activities. However, management and specialist efforts are not separated in Scrum.
  • Cross-functional: The Scrum Team has all the expertise and competencies needed to get the job done without any help from outside the team.

These two characteristics are designed to optimize flexibility, creativity, and productivity, needed for the Agile environment of Scrum.


Each Scrum project delivers the final product after a number of cycles, which are called Sprints. An Increment is developed in each Sprint. An Increment is a potentially releasable part of the final product. An Increment is a sum of all Product Backlog items completed so far in a project and this Increment keeps getting bigger after each Sprint. Therefore you can consider each new Increment at the end of a Sprint to be an updated version of the previous Increment with new features and functionalities, which may or may not be actually released (put into use), but should always be potentially releasable.

Customers usually request changes when they see the Increment (during the Sprint Review), and we note these new requests in the Product Backlog.

Sprint is a time-boxed event, which means we should fix its duration at the beginning of the project and not change it frequently or occasionally. Sprints are usually fixed for one month or less.

An important point is that we do not change the items of the Sprint Backlog after the Sprint is started and the plans are set. The Sprint Goal (discussed further in Sprint Planning) should not change either. The Product Owner and the Development Team might try to clarify and re-negotiate the scope as more is learned as more is leaned about the items to be delivered, but will not change the Sprint Backlog. Even the composition of the Development Team should not change during a Sprint. These constraints are designed to make it possible to focus and get things done.

Each item (story) in the Product Backlog should normally be developed (completed) in a single Sprint as this is much easier to manage. The Product Owner and the Development Team select a number of items from the top of the Product Backlog (this has already been prioritized by the Product Owner) and aim to get them “Done” (100% complete). We want them to be really “Done” when the Sprint is over, and create an Increment. An Increment is the sum of all the completed items during a Sprint and all previous Sprints.

It is important to agree on a definition of “Done” at the beginning of the project. We will not call something “Done”, unless it fits the definition. A 99.999% completed item is not considered as “Done”, it would not be part of the Increment and it would not be demonstrated to the customer at the Sprint Review.

print Time boxes: Most companies use Sprint time boxes of 2 to 4 weeks. If we use time-boxes longer than one calendar month for Sprints, it will be likely for the unapplied changes to become large enough to create problems. This will increase the complexity and risk. Therefore, we should keep the Sprints no more than one calendar month. Sprints should not be too short either, because we would not be able to produce complete Backlog items during it. Our goal is to deliver the final product item by item, inside the Sprints; we do not want to split a single Product Backlog item among several Sprints.

Can a Sprint be cancelled? Even though each Sprint is frozen and does not change, the Product Owner has the authority to cancel a Sprint. This can happen when the Sprit Goal becomes obsolete, due to changes in the Product Backlog, strategies, approach, etc. When a Sprint is cancelled, the items that are “Done” will be reviewed and accepted, and the rest of the items (not started or partly complete) will be put back into the Product Backlog to be done in the future.

Sprint Backlog

The Sprint Backlog is created during the Sprint Planning event which is the first event in a sprint. During the Sprint Planning event, the Scrum Team collaborates on creating the Sprint Backlog, which consists of the following:

  • A number of items selected from the top of the Product Backlog, based on their estimated work and the estimated capacity of the Development Team
  • The Sprint Goal, which will help describe the real meaning of the items and direct the efforts of the Development Team
  • A detailed plan for delivery of the items and realization of the Sprint Goal during the Sprint

The Sprint Backlog is frozen after the Sprint Planning and the Development Team will focus on delivering an Increment of “Done” based on this plan. The statement “the Sprint Backlog is frozen” means that items (stories) in the Sprint Backlog cannot be added or removed during the Sprint. However, it might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner. The detailed plan which is normally not complete at the end of the Sprint Planning, will continue to be updated as the Sprint continues.

Sprint Planning

The Development Team does not wait until the Product Backlog is 100% planned (all requirements are gathered and cleared) to start developing the project. As soon as the Product Backlog is mature enough (has the necessary number of stories) which will provide the information for the Sprint, the Product Owner and the Development Team can start the first Sprint.

The first thing to do in each Sprint is Sprint Planning. Sprint Planning is a time-boxed meeting, usually fixed to 8 hours for a one month Sprint, or shorter for Sprints of less than a month. All three roles should attend this meeting.

The Development Team should estimate the capacity of work it can deliver in a single Sprint. The Product Owner has already ranked and ordered the Product Backlog based on the value of the items. The Product Owner also ensures that the items (stories) are easy to understand. The Development Team then selects an appropriate number of items from the top of the Product Backlog, and puts them in the Sprint Backlog, to deliver in the current Sprint. The amount of work for each item is estimated by the Development Team and the total amount of work of the selected Product Backlog items is close to the estimated capacity of the Development Team.

Following the selection of the items, the Scrum Team should draft a Sprint Goal. The Sprint Goal is an objective that should be met within the Sprint through the implementation of the Product Backlog. The Scrum Goal provides guidance to the Development Team on why it is building the Increment.

The scope of the Sprint, which is made up of the items selected from the Product Backlog, might need to have more details through the Sprint. These details should be aligned with the Sprint Goal, and likely re-negotiations for them should be done in presence of the Product Owner. The Sprint Goal is also included in the Sprint Backlog.

When the items to deliver are selected and the Sprint Goal is agreed, it is time to plan how they will deliver the items into a “Done” product Increment and realize the Sprint Goal. This is the last part of the Sprint Backlog. The Sprint planning is not necessarily completed in this meeting; having a detailed plan for the first few days is enough; the Development Team can prepare detailed plans for the rest of the work later on.

A detail plan is a breakdown of a Product Backlog item into detailed tasks needed to be done in order to create the item. Each task might have estimates, dependencies, and similar information to make tracking possible.

The Sprint Backlog will be ready at the end of this meeting and the Development Team should be able to describe what items they will deliver through the Sprint, and how they will do it.

Sprint Retrospective

This meeting is normally three hours for a one month Sprint. If the Sprint is shorter than one month, this meeting will be proportionally shorter.

After the Sprint Review and just before the end of the Sprint, another meeting will be held, aimed at process improvement (learning lessons), which is called Sprint Retrospective.

There is a rule: we should always look for ways to improve. It does not matter how little the improvement is, there should be an improvement. This meeting is a formal opportunity for improvement, even though we do not limit our improvement to the results of this meeting. We will review (inspect) the Sprint, with regards to people, relationships, processes, and tools, and identify ways of improving them in the next Sprint.

Sprint Review

The duration of this meeting is normally four hours for a one month Sprint. If the Sprints are shorter then this meeting will be proportionally shorter.

At the end of the Sprint, the Scrum Team and other stakeholders gather and hold a four hour meeting to present and inspect the “Done” items (the Increment) from the current Sprint and adapt the Product Backlog by marking off “Done” items as complete and add new items or change the existing ones if necessary. The presentation of the Increment in this meeting is intended to collect feedback and raise change requests at the earliest time possible.

We welcome changes in Scrum and encourage them to be demanded, because it increases the satisfaction of the customer and will create a final product that better matches the needs of the customer.

The Development Team does not present an item, unless it is 100% complete based on the agreed definition of “Done”. The Product Owner makes sure (before the Scrum Review) that presented items are “Done”. The Development Team demonstrates and explains the items.

The Product Owner discusses the status of the Product Backlog and the likely completion dates based on the progress.

Finally, the whole Scrum Team collaborates on revising the Product Backlog based on the output of the Sprint and the feedback received from the customer.


Time-box is an essential concept in Scrum. It is our way of staying focused and getting things done in an ever-changing environment. A time-box is a fixed period of time in which we freeze the target and work with full focus on certain tasks or objectives. Time-boxed events repeat many times, until the final goal of the project is achieved. All the changes are applied only when one time-box is finished and we are ready to start the next one.

The duration of a time-box should be agreed upon and fixed. We are free to change the duration based on lessons learned, but not frequently, and never based on single occasions. For example, we are not allowed to say that “we have a lot to do this time, so let’s increase the duration for this particular case”. What we are allowed to say is “based on the previous ten time-boxes, we realized that the duration of our time-boxes is not suitable, and a 30% increase in duration might better fit our needs. So, let’s increase them from now on”.

Scrum Awareness, One Step a Day (free)

Start learning Scrum by spending less than 2 minutes per day. Lessons will be emailed to you. [more info]


No comments yet.

Leave a Reply