Scrum Now!: Scrum Glossary

Index

The Backlog or Product Backlog is a prioritized list of User Stories (and often Defects and Technical Debt items) that have not been assigned by the Product Owner to a particular release. Items at the "top" of the backlog have the highest priority and, ideally, will be the next items added to a Release Backlog.

Backlog Grooming (ceremony)

Some Teams engage in a periodic or recurring ceremony where the Product Owner and the Scrum Team engage in Backlog Grooming. While this is not a defined Scrum Ceremony, many Teams find it useful. Engaging the Team in Backlog Grooming helps keep the Team informed about the items in the Backlog and can assist the Product Owner in prioritization of items -- especially Technical Debt items that may be more difficult for the Product Owner to prioritize.

Backlog Grooming (process)

Backlog Grooming is a process where the Product Owner, and possibly the Team and other stakeholders, look through the Backlog and identify stories that need to be removed, improved or turned into Epics. The purpose of the activity is to keep the Backlog relevant and ensure that the items in it can be sized and worked. The Product Owner may also re-prioritize items in the Backlog as part of the Grooming process.

Burndown Chart

Also known as the Task Burndown Chart.

A chart comparing the team's daily estimated hours remaining on tasks within a Sprint to an idealized trend line. The trend line starts with the initially estimated task hours for the sprint on the sprint start date and ends with a value of zero hours at the end date for the sprint.

Task Burndown Chart for a small team. The Y-axis represents hours remaining for task work in the Sprint. The X-axis represents the days in the Sprint, skipping weekends and holidays. The blue trend line shows the ideal burn-down of hours in the Sprint. The red line shows the Team's estimated hours remaining to complete those tasks at the end of each work day. This particular chart is maintained on a whiteboard. More typically, a flip chart or butcher paper taped to a wall is used.

This chart is useful for determining the health of the Sprint. Values above the trend line indicate that there may be an issue completing all the items committed to in the Sprint. Values below the trend line indicate that the team is progressing faster than expected. While some variance from the trend is normal, extreme changes are usually either danger signs or indications that the Team needs to work at making better task estimates.

It is normally posted in a public traffic area where it is visible to the Team, management and any other interested parties.

It's important to note that if this is a Task Burndown Chart, the units are in hours, not story points. Some teams use a Story Burndown Chart, which compares a similarly idealized trend line to the number of story points completed and accepted by the Product Owner.

Note that there are other types of burn-down charts, but the primary Burndown Chart used in Scrum compares daily estimated hours to an ideal burn-down of the Sprint.

Ceremony

Any of several Scrum meetings. The defined ceremonies are:

Scrum (a.k.a.: Daily Stand-up)
Sprint Planning
Sprint Review
Sprint Retrospective
Release Planning
Release Retrospective

Some Scrum teams also include other ceremonies that are not technically Scrum, but are complementary additions. Examples are:

Story Sizing
Backlog Grooming

Continuous Integration

Continuous Integration (CI) is a practice borrowed from eXtreme Programming where the build system is automated in such a way that after code is checked into source control by a Developer, the entire codebase is built, all unit tests are run and a deliverable installation package is generated. Often, CI systems will also deploy the newly-built system to one or more test servers.

CI systems also generate reports and notifications as side-effects of the build and testing. Usually the reports include metrics on code complexity, code coverage and other code analytics. Notifications will go out to everyone on the team indicating whether or not the build and tests were successful or not. If the code will not build or if automated tests fail, a notification will go out indicating that the build has been "broken" and by whom.

CI encourages developers to only check-in work that is complete and that has been tested. It also provides an automated system to simplify the deployment of code to Quality Assurance platforms, speeding up the turnaround of QA activities.

Daily Stand-up

c.f.: Scrum (ceremony)

Developers

Developers on a Scrum Team include Software Engineers, Quality Assurance Engineers and often Technical Writers and Graphic Artists.

Teams that embrace eXtreme Programming will normally not make a distinction between any of these roles, simply referring to all Team members as Developers and with the expectation that any team member can fulfill any role as needed to complete the Sprint.

Done

In Scrum, Done means that a feature is ready for delivery and/or use by the customer. Each Team should have their own definition of Done, which should be displayed prominently and reviewed regularly as part of Release Planning and Sprint Planning.

Having a well-defined definition of Done allows Teams to know when a Story is complete. While, on the surface, "done" seems to be a well-understood concept, codifying Done reveals the specific product eccentricities and processes that must be completed that might not be so obvious.

Epic

An Epic is a User Story that either already acts as a feature arc for a collection of smaller stories or a User Story that is determined to be too large and should be broken up into smaller deliverable units. Epics are often identified during Story Sizing when a story requires more Story Points than can be completed by the Team in a single Sprint.

eXtreme Programming

eXtreme Programming (XP) describes a set of Agile Practices and philosophies. Kent Beck summarized XP in his 1999 book eXtreme Programming Explained: Embrace Change. The main concepts of XP are:

Continuous Integration
Continuous Delivery / Short release cycles
Paired Programming
Test-Driven Development
Everybody on the team is responsible for quality

XP can generally be combined well with Scrum because where Scrum describes a framework of processes, XP focuses on Developer practices. It is very common to see Scrum teams adopting XP practices such as Continuous Integration, Paired Programming and Test-Driven Development.

Paired Programming

Paired Programming is a practice borrowed from eXtreme Programming where Developers work in pairs to complete non-trivial stories or defects. Typically, one Developer is designated as the Driver and the other as the Navigator. The Driver controls the keyboard and other input devices and writes code while talking to the Navigator about what she is doing and why. The Driver's focus is on the current elemental portion of the task at hand. The Navigator watches the Driver, reviewing the code that is being written as it is being written and is responsible for thinking about how the current piece that is being worked on will fit into solving the current problem. Developers are encouraged to switch roles at regular intervals -- usually every half-hour or hour.

Two Developers engaged in Paired Programming.

The advantages of Paired Programming are:

Constant peer review;
Fewer first-generation defects;
Constant design review and refinement;
Typically greater job satisfaction;
Constant training and cross-training;
Team building.

A typical Paired Programming work area for use with a laptop computer. Note the docking station in the upper-right corner. In this configuration, both keyboards and mice are active.

Product Owner

Product Owner is one of the three roles defined in Scrum. The Product owner's primary responsibilities are:

Determining and maintaining the priority of stories in the Backlog and Release Backlog;
Accepting (or rejecting) User Stories as they are completed or as they are presented in the Sprint Review;
Grooming of the Backlog.

While the bullet point is often considered the collective responsibility of the Product Owner and Team, the ultimate responsibility for keeping the Backlog groomed lies with the Product Owner.

The Product Owner is also often responsible for scheduling and setting the agenda for the Release Planning Ceremony and the Story Sizing Ceremony (if this task is performed separately from Release Planning).

Release

In Scrum, a Release is a Time Box associated with one or more Sprints. It defines both a period of time and the anticipated features to be worked as part of the release.

Release Backlog

The Release Backlog is a prioritized list of items (User Stories and Defects) scheduled to be worked in a particular Release. It represents items that have not yet been assigned to a particular Sprint and, as a Release nears completion, contains items that may not make it into the final release. Like the Backlog, the Release Backlog is maintained and prioritized by the Product Owner.

Release Planning

This is a Scrum Ceremony organized by the Product Owner where the general theme of a product release is presented and discussed as well as the specific User Stories and Defects that are desired for the realization of that theme. It is intended as a vehicle for doing high-level planning between the Product Owner and the Scrum Team as well as for setting Stakeholder expectations.

A typical agenda for a Release Planning Ceremony is as follows:

The Scrum Master, who acts as moderator, welcomes the participants, reviews the agenda and presents the Product Owner.
The Product Owner reviews the overall product vision and roadmap.
The Product Owner gives a "State of the Product" overview.
The Product Owner then presents the release Name (or version number) and theme.
The Product Owner or Scrum Master presents the release schedule, number of iterations and current team Velocity.
Often, the team then reviews its Definition of Done
The Product Owner then presents the Release Backlog intended for the Release.
The Team, using the Product Owner and Stakeholders for reference, sizes the stories.
The stories are mapped preliminarily, by Priority, into the Release's Sprints.
Issues and concerns are discussed.
The meeting is restrospected, moderated by the Scrum Master.
The meeting is closed by the Scrum Master

Teams that perform periodic Story Sizing as a separate Ceremony will often not need to perform the Sizing activity.

For an example of a more expansive Release Planning agenda, see the Rally Guide to Release Planning.

Release Retrospective

This is a Scrum Ceremony for the Team to review its performance and concerns across a Release Time Box. It is similar to the Sprint Retrospective in purpose: to build the team, identify problems that need correction, praise admirable behavior and performance and come up with action plans to constantly improve each release.

The format and tone of a Release Retrospective is normally quite different from a Sprint Retrospective. Whereas the Sprint Retrospective is focused on immediate problems, Team morale and process tweaking, the Release Retrospective is more about fact-finding and action planning. It tends to be less driven by emotions and more focused on facts. It is also intended to be a celebration of the Team's success at delivering the features of the release. Snacks and party foods are often provided.

The core questions to be answered are:

What features were delivered and at what level of quality?
How well was the Team able to make and keep its commitments?
What did the Team learn over the course of the Release that will improve future Releases?
What behaviors or practices does the Team need to eliminate or change that will improve future Releases?

A typical Release Restrospective agenda looks something like the following:

Opening by the Scrum Master
A presentation of the overall goals for the Retrospective
A "safety check" to ensure everyone is comfortable with the rules of engagement for the Retrospective
Data gathering -- this can take many forms, including Timelining, Mind Mapping and Post-It Blurbs.
Generate Insights
Develop an action plan for future Releases -- potentially refining processes and even the Team's definition of Done.
Team appreciation, where Team members are encouraged to share their appreciation of each other
Celebration -- this is were the snacks come in.

Scrum (ceremony)

The Scrum or Daily Stand-up is an informal meeting that the team uses to organize their work for the day. In a typical Scrum, each team member answers some form of the Three Questions. The Scrum Master is responsible for taking note of any Roadblocks reported and then working to remove them after the meeting. Participants are encouraged to offer help if a team member needs it, though this should never become a Problem Solving session.

In a strict sense, only "Pigs" may speak during the Scrum with the Scrum Master acting as a moderator. Pigs are the Scrum Team and the Product Owner. At times, other attendees, designated Chickens, may be invited to speak or respond to questions from the Team, but as a general rule, Chickens are expected to remain silent, allowing the team to organize itself around the work of the Sprint.

The Scrum typically lasts no more than ten to fifteen minutes. It is typically conducted with all team members standing in order to encourage brevity. Ideally, the Scrum should be conducted in the Team's main work area and in front of the Task Board and Burndown Chart.

Scrum (process)

An Agile process framework first proposed in 1978 by Hirotaka Takeuchi and Ikujiro Nonaka for organizing development teams in a holistic fashion. The Scrum methodology was further refined by Ken Schwaber, Jeff Sutherland and others in the early 1990s. Schwaber and Sutherland presented a white paper on their codification of Scrum at the OOPSLA '95 conference in Austin, Texas, USA.

Scrum describes a set of processes (referred to as Ceremonies) that happen during well-defined and constrained periods of time, known as Time Boxes. These processes and the accompanying Scrum philosophies are focused at enabling software development teams to self-organize around software projects. Scrum is all about the empowerment of teams to set their own goals for quality and create reasonable expectations for delivery of software products. It creates an environment where code can be delivered to market often in small, feature-complete increments.

Scrum Framework

c.f.: Scrum

Scrum Master

Scrum Master is one of the three defined roles in Scrum. She acts as a moderator for all of the Ceremonies and is responsible for finding a resolution path for any obstacles (Roadblocks) presented by the team during the Daily Scrum.

Scrum Masters are also typically responsible for training Teams on Scrum principles and for determining when process changes should be made in order to keep the team Agile.

Ideally, the Scrum Master should be a singular role -- the person in that role should serve only in that capacity on one or more teams. Often this is not the case and one of the Team members serves in a dual capacity as Team member and Scrum Master.

Product Owners and Managers should never serve as Scrum Masters. It can be done, but it is always a less-than-optimal situation and is not the best way to serve a Scrum Team. (The author speaks from experience on this matter, having held the dual role of Scrum Master and Development Manager.)

There is a Scrum Master certification available through the Scrum Alliance and it is recommended that all practicing Scrum Masters be certified, since certification includes training on the Scrum Framework.

Scrum Team

A Scrum Team (often referred to in this blog and glossary as "Team") is composed of Software Engineers, Quality Assurance Engineers, Technical Writers and Graphic Artists working together to complete a specified set of features for a software product. The members of the team are often collectively referred to as Developers, regardless of their role.

While the Product Owner and Scrum Master are philosophically members of the Team, their roles are intentionally segregated when discussing their specific responsibilities.

In terms of designating Chickens and Pigs, all members of the Scrum Team are Pigs, as is the Product Owner. The Scrum Master, Development Managers and Stakeholders are considered Chickens.

Sprint

A Sprint, which in Agile nomenclature is often referred to as an "iteration", is a periodic Time Box within which a specific increment of deliverable functionality is created. Sprints are typically two to four weeks long, with the duration normally defined by the team.

A Sprint normally starts with a Sprint Planning Ceremony, during which the Team commits to delivering a specific increment of product functionality. Ideally, the work product produced at the end of any given Sprint should be in a condition where it could be released to a production environment. This is the goal that Scrum Teams should strive for in every Sprint.

Sprint Planning

Sprint Planning is a Scrum Ceremony that takes place at the beginning of each Sprint before any work towards the Sprint's deliverable functionality is started. The Team, in conjunction with the Product Owner, reviews the items from the Release Backlog that have been selected for the Sprint, clarifies their understanding of the Stories or Defects presented, defines the tasks required to complete each item and estimates the time required to complete each task.

The Product Owner initially uses the Team's Velocity to decide how many items from the Release Backlog should be presented for inclusion in the Sprint, but the final set of items is determined by comparing the Team's available hours to the estimated task hours required for the stories presented. If the estimated hours are greater, the Team and the Product Owner negotiate to either reduce the scope and tasks of the stories to be included or to remove the lowest priority stories from the Sprint.

The final work product of the Ceremony is a list of Stories and associated tasks that the Team and Product Owner are comfortable committing into the Sprint with the goal of delivering all items as an increment of deliverable functionality.

A typical Sprint Planning agenda looks like the following:

The Scrum Master opens the meeting and reminds the team of its purpose
The Product Owner and Team decide on a name for the Sprint
The Product Owner (sometimes in conjunction with the Team) presents/defines the theme of the Sprint. (The theme is useful later in the sprint for reminding the Team of what it's trying to accomplish.)
The Team members then state what their available work hours for Sprint items are. This way the Team accounts for holidays, vacations, meetings, on-call duties and other maintenance activities that are either known or buffered for.
The Product Owner reviews the Team's Velocity and presents the stories that she wishes to go into the Sprint that can be accommodated by that Velocity.
The team reviews each item and creates tasks for it, assigning an estimate of time required to complete each task. Depending on the Team, individuals may be assigned to the task at this time or it may be left until the task comes up to be worked.
After all of the items have been tasked, the total hours required to complete all tasks is calculated and that total is compared to the Team's available hours.
At this point, a negotiation occurs to remove stories or decrease scope, or additional stories are added and tasked out.
Once the Team and Product Owner are satisfied that the Sprint has been right-sized, the entire Team is polled individually on their confidence in the Team's ability to deliver all items in the Sprint. This is normally done with a "Fist of Five" vote. If the Team's confidence is too low for the Team to make a commitment to the Sprint as it is currently defined, another negotiation occurs. This repeats until a reasonable level of confidence can be established.
The Team commits to the Sprint. Many teams will perform a cheer or common gesture to signify that commitment.
The Scrum Master then closes the Ceremony.

Sprint Review

The Sprint Review (also referred to as the Sprint Demonstration) is an informal Scrum Ceremony where the Team presents the work it has completed during a Sprint for approval by the Product Owner. Presentations are made from the running product from a staging server -- there should be no PowerPoint slides shown as a substitute for the actual running product. Invitations to a Sprint Review are often open to everyone, but should include stakeholders, product support staff and training staff.

While the Product Owner is the primary audience member, all attendees are invited to comment and submit suggestions. It is not unusual on some teams for cosmetic suggestions to be implemented or evaluated during the Sprint Review.

The Agenda for a Sprint Review tends to be very simple:

The Scrum Master welcomes everyone to the review and states the theme of the Sprint.
Each work item is presented using a screen projection (and possibly web-based screen sharing) and comments are invited.
As each item is presented, the Product Owner is asked to Approve each item or indicate what re-work may be needed.
After all items have been presented, the Scrum Master review any action items or changes that have been approved by the Product Owner for further action. These typically result in the creation of new User Stories or Defects.
The Scrum Master invites final questions or comments.
The Scrum Master thanks everyone for their participation and closes the ceremony.

Sprint Retrospective

The Sprint Retrospective is a Scrum Ceremony where the Product Owner and Team review what went well and what went badly during a Sprint. The discussion is geared toward constant improvement and usually produces a number of action items to be accomplished as part of future Sprints. It is the last Ceremony in the Sprint Time Box.

The Sprint Retrospective is designed to be a safe environment where people can air their issues while not casting blame and not fear any form of retribution for speaking honestly. It is also a Ceremony where Team members are encouraged to complement and support one another. In strong Scrum Teams this tends to happen naturally.

The main feature of most Sprint Retrospectives is some form of game designed to get Team Members to reflect on the Sprint and how it could be improved. A common game is the "Good/Bad" game. In this game, each participant is given a stack of Post-It notes and is encouraged to write down things that happened during the Sprint that were either good or bad, writing one event per note. They then place their notes on a whiteboard that has been divided vertically with the headings "Good" and "Bad" above the two columns. The Scrum Master then reads the items, which can remain anonymous and they are discussed.

A whiteboard used for the "Good/Bad" game with Post-It notes attached.

There are many such games and a lot of resources on the 'Net for them. One of my favorites is the free booklet "Getting Value Out of Agile Retrospectives", which has a number of good retrospective games in it.

Story Card Format

Story Card Format (often referred to as Card or Carding) is a typical method used for defining or starting a User Story. The format is: "As a ______, I want to ___________ in order to ____________." The purpose of the Card is to get the story writer to focus on what the story needs to accomplish and avoid defining the mechanics of how it gets accomplished.

Carding has become a hot topic lately with a number of proponents an opponents. Unfortunately, the Card gets confused with the User Story and you will see opponents of Carding deriding the User Story itself, when their issues are with the Card Format.

The bottom line is that the User Story has value and is required in Scrum. The Story Card Format is a tool for defining User Stories that teams may opt to use. As with many things in Scrum, how you flesh out the framework is up to you.

Story Points

Story Points are an intangible metric for estimating the relative size of a Story or Defect. An entire whitepaper could be written on the topic of Story Points (and many have), but the definition above sums up what they are. It's the why that requires more explanation than is appropriate for a glossary entry.

It should be noted that most Teams estimate in terms of either T-Shirt sizes (S, M, L, XL, XXL) or using a modified Fibonacci sequence (0, 1, 2, 3, 5, 8. 13. 20, 40, 100, ∞). The Fibonacci values are more conducive to making calculations of Velocity, though many teams will map T-Shirt sizes to specific Fibonacci values.

Task Board

A Task Board (sometimes called a Story Board) is usually an area of a wall that has been divided into columns indicating work that has not been started, work that is in progress, work that is completed and, often, work that has been accepted by the Product Owner. It is normally placed in a high-traffic area of the Team's work area where it can be easily seen by the team, Product Owner and management.

These boards take many forms. The classic form uses large index cards to indicate the story and smaller index cards or Post-It notes to indicate the tasks. There are also electronic versions of the Task Board in groupware tools like Microsoft Team Foundation Server and Rally.

Aside from the obvious purpose of keeping track of the state of stories within a Sprint, the Task Board promotes Transparency and is a very visible statement of the Team's progress and goals.

Test-Driven Development (TDD)

Test-Driven Development is a practice borrowed from eXtreme Programming where Developers write tests before writing the code that is to be tested. The basic idea is that unit tests should first fail and continue to do so until the programmer has created just enough code to cause the test to pass. He then writes another test to expand the expected functionality and repeats the process.

The advantage of TDD is that it guides developers to write only the code that they can test, avoid future-proofing and produce code that is truly unit testable. Another bonus is that unit test code coverage is pretty much guaranteed to stay in the high 95% range and above.

Time Box

The Time Box is a Scrum term that comes from the project management world. It defines a specific, fixed and bounded period of time during which an activity or series of activities should occur. Scrum defines a number of Time Boxes, of which the Sprint Time Box is the most apparent. The fact that Sprints are timeboxed can often lead to contention because of the perceived need to extend a Sprint rather than accept that a Team has not met its commitments.

User Story

A User Story describes a deliverable and testable unit of work in such a way that all parties involved understand what the purpose of the feature is as well as what Acceptance Criteria will be required in order for the Team to declare the story Done. It is important to note that a User Story is not the same as a Use Case and, in fact, a Story may contain or be defined in terms of several Use Cases.

User Stories often use the Story Card Format for starting the card, but this is not necessarily a requirement and many teams use different methods for defining a User Story.

Velocity

Velocity is a calculated value used in Release Planning (and to a lesser degree in Sprint Planning) to estimate the team's capacity for working stories from the Backlog. It is calculated as an average of the number of story points completed and accepted from the most recent Sprints. The typical calculation is based on the three most recent Sprints, but Teams can sometimes use a larger number of Sprints for the calculation.

As noted above, Velocity is primarily used for estimating a Release. The Project Owner will typically define a Release period and divide it into a number of Sprints. He will then multiply the number of Sprints by the current Team Velocity to determine the capacity of the Release in terms of Story Points, yielding the formula

Velocity x Sprints = Capacity

The Project Owner will then add stories until the capacity of the release has been reached. Those stories make up the Release Backlog that will be presented to the Team and stakeholders in the Release Planning Ceremony.

It's important to note that Velocity is subject to change, which is why it is important to re-evaluate velocity on an on-going basis. Changes in personnel or estimating methodology and improvements in process, among other things, can affect Velocity.

Scrum Now!

Scrum Glossary