Glossary

In agile development, a feature is a chunk of functionality that delivers business value. Features can include additions or changes to existing functionality. For planning purposes, some agile methodologies also use the notion of "work items" that can include features, bug fixes, documents, and other artifacts. But features are the main unit of planning. 

The various agile scrum methodologies share much of the same philosophy, as well as many of the same characteristics and practices. But from an implementation standpoint, each has its own recipe of practices, terminology, and tactics. Here we have summarized a few of the main agile software development methodology contenders.

A common codebase is, simply, shared by as many programmers on the team as possible. This is only practical if the team is using test-first programming, refactoring, continuous integration, and a single coding standard. It is also greatly assisted by agile pair programming.

Whether you have just wondered about agile project management, or actually dipped a toe in, you would probably agree: the role of the project manager can seem impossible. Customers expect quality software on time and on budget. But wait! The requirements just changed. Again.

What is a release plan? Planning and estimating in the agile world depend on a single key metric: the development team's velocity, which describes how much work the team can get done per iteration. Given a team's known velocity for its last project (if it is known), a release plan represents how much scope that team intends to deliver by a given deadline.

Agile methods grew out of the real-life project experiences of leading software professionals who had experienced the challenges and limitations of traditional waterfall development on project after project. The approach promoted by agile development is in direct response to the issue associated with traditional software development both in terms of overall philosophy as well as specific processes.

The iteration or sprint planning meeting is for team members to plan and agree on the stories or backlog items they are confident they can complete during the sprint and identify the detailed tasks and tests for delivery and acceptance.

Iteration lengths typically range between one and four weeks. The team holds a planning meeting at the beginning of each iteration to break down each of the features scheduled for the iteration into specific technical tasks. Iteration or agile sprint planning meetings generally last from two to four hours - any more than that and you may be spending too much time in unnecessary planning; less time than that and you may not be doing enough planning and collaborating.

As teams progress through an iteration, it is important to understand the state of the iteration. As dozens or even hundreds of tasks are worked on within the iteration, measuring progress and remaining effort (or, "to do") become critical. This is especially true on larger projects.

Within an iteration, the remaining effort represents the true state of an iteration at any given time. As the iteration progresses, the remaining effort required to complete the iteration's tasks should obviously be decreasing. Not all tasks will necessarily be identified during iteration planning. Some may only be identified as current tasks are progressed and completed. By consistently managing the total remaining effort of all the tasks, a very clear picture of the overall iteration's status is understood. If at any given point during the iteration it appears that the work is not approaching zero by the end of the iteration, then the team and/or management may elect to take appropriate measures, such as reducing scope.

Agile velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. To calculate velocity of your agile team, simply add up the estimates of the features, user stories, requirements, or backlog items successfully delivered in an iteration.

Projects that exhibit agile development success seem to share several key characteristics that are summarized below. For some methodologies these correspond exactly with individual practices, whereas for other methodologies there is a looser correspondence.

Code refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to iteration, and without continuous refactoring, this is hard to do. This is because un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, way too many responsibilities per method or class, duplicate code, and many other varieties of confusion and clutter.

See our list of common agile scrum terms.

Traditional software development methods don't dictate how frequently or regularly you integrate all of the source on a project. Programmers can work separately for hours, days, or even weeks on the same source without realizing how many conflicts (and perhaps bugs) they are generating. Agile teams, because they are producing robust code each iteration, typically find that they are slowed down by the long diff-resolution and debugging sessions that often occur at the end of long integration cycles. The more programmers are sharing the code, the more problematic this is. For these reasons, agile teams often choose to use continuous integration.

Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like scrum, kanban is a process designed to help teams work together more effectively. 

Agile teams committed to frequent, regular, high-quality production find themselves striving to find ways to keep short-term and long-term productivity as high as possible. Proponents of pair programming ("pairing") claim that it boosts long-term productivity by substantially improving the quality of the code. But it is fair to say that for a number of reasons, pairing is by far the most controversial and least universally-embraced of the agile programmer practices.

Scrum is an agile project management methodology or framework used primarily for software development projects with the goal of delivering new software capability every 2-4 weeks. It is one of the approaches that influenced the Agile Manifesto, which articulates a set of values and principles to guide decisions on how to develop higher quality software faster.

Use scrum project management to deliver working products with more business value. Scrum project management is a methodology for managing software delivery that comes under the broader umbrella of agile project management. It provides a lightweight process framework that embraces iterative and incremental practices, helping organizations deliver working software more frequently. Scum project management provides project progress via a series of iterations called sprints; at the end of each sprint the team produces a potentially deliverable product increment.

Agile teams often find that the closer the unit test coverage of their code is to some optimal number (somewhere between 75% and 85%, many teams find), the more agile their code is. Which is to say, it is easier for them to keep the defects in the code to very low levels, and therefore easier for them to add features, make changes, and still deliver very low-defect code every iteration. After experimenting with different ways to keep test coverage up at those optimal levels, agile teams hit upon the practice of test-first programming.