Agile Glossary

All | A B C D E F H I K L M N P R S T U V W
There are currently 4 names in this directory beginning with the letter B.

An ordered list of items to be worked on, where the most important items are at the top of the list, and the least important items are at the bottom of the list. It is a common practice for the items at or near the top of the list to be much better articulated (that is, have more descriptive information) than those at the bottom, because especially when backlogs contain a large number of items, those at the bottom of the list might never be worked on, due to shifts in priority and other business constraints. See also Product Backlog; Sprint Backlog.
Submitted by: Phil Rogers

Backlog Refinement
Many teams have planning conversations in addition to those that are formally part of Scrum, for instance. Backlog refinement is typically a conversation during which some or all team members seek to make various work items "ready" for the team to work on. It is also common for items to be added to or removed from the Product Backlog. For Scrum teams, it is common for backlog refinement to take place about once per Sprint. (Backlog refinement is not formally part of Scrum, however, it is common enough that it has been referred to as a Generally Accepted Scrum Practice, or GASP.)
Submitted by: Phil Rogers

Behavior Driven Development
A synthesis of practices originating with Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD), BDD augments TDD and ATDD in the following ways: applies the “Five Why’s” principle to each proposed user story, so that its purpose is clearly related to business outcomes; thinking “from the outside in”, in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste; describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication; apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains inexpensive.
Submitted by: Phil Rogers

Brook's Law
Although a common reaction when a project is thought to be behind schedule is to add people to the effort, the impact of the addition of more people is that it initially slows the project down. The term is named after Fred Brooks, author of a book called the Mythical Man Month, in which he describes this phenomenon. He observes that the time it takes for people added to a project to become productive is "ramp up" time, because as they learn the new problem space, they typically need to rely on one or more existing team members for information, which slows those team members down, at least for a period of time. diminishing their productivity while the new workers are not yet contributing meaningfully. Another impact of making a team larger is that the increases in the number of communication channels results in an exponential increase in communication nodes (as more people are added they spend more time trying to find out what everyone else is doing).
Submitted by: Phil Rogers