Product Backlog? Scrum Master? Burndown Chart? What do all these terms mean?

To make life easier for those who are starting the Scrum, I prepared a glossary explaining the most common terms used in Scrum.

This glossary can be used for quick reference, but can also be used to give you an overview of the Scrum methodology which is used in agile software development communities.

Scrum Glossary

Burndown ChartThe purpose of a burndown chart is to present the portion of work completed, compared to the work that was planned. This graph shows two lines: one representing the planned work as if it ran uniformly along the Sprint and the other featuring the work that was actually completed by the Development Team. It is common for the Development Team to use this chart throughout the Sprint, in order to measure the points completed over the stories of the days of Sprint and have a sense of pace, making sure it is they will be able to achieve their Sprint goal in time.

Burnup Chart – The purpose of a burn up chart is to present the progress of work towards the final product. In this chart, there are two lines, one showing the progress of the Product Backlog (this may increase as the project is being developed) and the other showing the progress of what has been accomplished by the team during the Sprints already completed. It gives visibility of project progress.

 

Daily Meeting

Meeting that occurs daily, preferably in the early morning or late in the day.

With participation of the Development Team and Scrum Master.

The meeting is held with all participants standing up.

A maximum of 15 minutes.

The purpose of this meeting is to communicate what is happening to show transparency in the Development Team.

It is a short meeting to focus on transparency and non-technical discussion of the problems and solutions.

It is a meeting where team members make commitments to others. Responding to three questions:

1. What did you do yesterday?

2. What will you do today?

3. Are There obstacles in your way?

 

Development Team – This is one of three roles in Scrum. The development team is responsible for the development of the Sprint, working on the tasks of each Story to reach a final product.

 

Estimate– Score system to estimate the effort required to implement a Story. Estimates may be in story points, following the punctuation used in planing poker.

 

Impediments – problems that arise during the Sprint and prevent the team from working on, or completing a Story. The resolution of impediments are the responsibility of the ScrumMaster.

 

Planning Poker – A technique for estimating the product backlog stories. It is based on the use of cards, such as poker, each having one of the following numbers. The numbers are based on the Fibonacci series. The numbers are: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100.

 

Planning Meeting 1

Meeting held at the beginning of Sprint, to plan for it.

With mandatory participation of the Product Owner, Scrum Master and Development Team.

Maximum duration of 2 hours for Sprints timeboxed for 2 weeks.

At that meeting, Prepared Stories are presented in the sequence found in the Product Backlog and the Development Team and Product Owner argue about each of these Stories, to clarify the details of what should be implemented and, if necessary, allow adjustment points estimated by the Development Team.

At the end of the meeting the Sprint should be created with a start and an end date, respecting the timeboxed of Sprints and have selected the stories that will be part of the Sprint Backlog. Usually the stories included are based on point estimates and limited the speed of the Development Team.
 

Planning Meeting 2

Happens after the first Planning Meeting 1.

Planning meeting for the Development Team to work at the Sprint.

Maximum duration of 2 hours to Sprints timeboxed 2 weeks.

At this meeting the team divides each Story into Tasks.

These tasks can be noted on post-its and attached to the Job Board for greater transparency of progress along the Sprint. Or posted in a software that supports Scrum.

 

Product Backlog – List of items or stories that should be implemented to create the desired product or project development.

 

Product Owner – It is one of three roles in Scrum. The Product Owner is responsible for the Product Backlog. He is the one who defines and prioritizes the desired features for the product, or the activities required for the project, describing them in the form of stories in the Product Backlog.

 

Retrospective Meeting

Held after the Review Meeting.

With participation of the Development Team and Scrum Master. The PO should participate only if invited.

Maximum duration of 2 hours to Sprints timeboxed 2 weeks.

The goal is to inspect the finished Sprint to allow adaptation.

At this meeting the team must raise the positive and negative points of the Sprint and at the end of the discussion they should be taken as a final result a list of actions to improve the process as a whole.

 

Review Meeting

Performed at the end of each Sprint.

With participation of the Development Team, Scrum Master and PO.

Maximum duration of 2 hours to Sprints timeboxed 2 weeks.

The purpose of this meeting is to present to the PO what happened during the Sprint.

The PO should than approve or reject each Story.

 

Scrum MasterIs one of three roles in Scrum. The Scrum Master acts as a facilitator of the development team and help the Product Owner, helping to maintain the Product Backlog, removing obstacles and protecting the Development Team from external interference, to ensure productivity and work efficiency. Scrum Master is seeking to ensure the use of values and practices of Scrum.

 

Scrum – Is an Agile Methodology for management and project planning. For more information read the post “What is Scrum? – Scrum FAQ” in our blog.

 

Speed – Total points of Stories that the development team can run in a Sprint.

 

Sprint – Represents a work cycle in Scrum. This cycle can be 2 weeks, 3 or 4 weeks, which is timeboxed of Sprints. Sprints should always have the same duration.

 

Sprint BacklogList of Stories to be worked on during a sprint.

 

Sprint Goal – The goal of Sprint is what the PO expects to achieve at the end of Sprint and is what should guide the work and efforts of the Development Team throughout the Sprint.

 

Stand-Up Meeting – See Daily Meeting.

 

Story: "Done"– A "Done Story" is a Story completed during a Sprint, ready to be submitted to the PO for evaluation. The “Done” story is presented to the PO in the Review Meeting, so he can accept it or reject it. The definition of "done" is made up in an agreement between the PO and the Development Team.

 

Story: "Ready" – A Story that is ready to be estimated by the Development Team in order to be included in a sprint. The definition of "ready" is made up in an agreement between the PO and the Development Team.

 

Story Points Represents points in the effort of the Development Team to complete a Story. See what the points are on Planning Poker.

 

Tasks – The Stories in each Sprint should be broken down into tasks that represents a maximum of 1 working day of a member of Team Development. Therefore, Stories should be broken down into smaller, one-day (maximum) Tasks.

 

Task BoardItems used by the team to present the work that must be implemented by the Development Team. The most common division of this framework is given as an array of three columns that are: To Do Tasks, Tasks in Progress and Completed Tasks, and where each line represents a Story of the Sprint Backlog. At the start of the Sprint All tasks are concentrated in the first column (To Do Tasks) and all tasks are expected to be at the Completed Tasks column by the end of the Sprint. The task board gives the team a way to see the progress of the work during the Sprint, it is updated daily or whenever a member of the Development Team takes responsibility for giving way to a task of a history.

 

TimeBox – The time scale set for the Sprint project.

 

User Stories -These are the Product Backlog items that represent part of the product to be implemented. Stories should contain a detailed description of what should be implemented.