Updated: Mar 22
Agile. Easy to understand, difficult to master.
Agile introduces lots of new terminology - Isn't Scrum something rugby players do? Who is this mysterious 'Master' and why do they want me to Sprint?!
Relax. All will be explained, right here. Here are the most common terms - defined - to improve your understanding.
pro-tip: Looking for a specific term? Press ctrl+f (cmd+f for mac) and type in the term you're looking for.
Agile Application Lifecycle Management
Also called Agile ALM, Agile Application Lifecycle Management is the integrated management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.
Agile practices are procedures that are defined as being highly efficient and include the following practices: user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burn-up charts, burn-down charts.
Agile development is a way of thinking about software development as expressed in the Agile Manifesto and acts as an “umbrella” for a group of methodologies. The methodologies are based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organising, cross-functional teams. Agile development is a conceptual framework that promotes evolutionary change throughout the entire life cycle of the project and represents a new, more flexible approach to development than the traditional methods that have previously been the norm for software development.
Agile Development Life Cycle
The complete software development process including Agile practices such as user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burn-up charts, burn-down charts.
Agile Project Management
The process of planning, organising and managing the necessary resources in order to complete project goals while adhering to Agile practices.
A software development methodology based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organising cross-functional teams and are collectively regarded as highly efficient to productivity. Specific processes include user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burn-up charts and burn-down charts.
Agile Development Process Tools
Tools necessary to complete the application development process, such as Application Lifecycle Management tools, Software Configuration Management tools, Build and release tools and security and defect tracking tools.
Agile SCM Tool
Software Configuration Management tool that supports Agile Software Development Lifecycle requirements differently than requirements involved with traditional software development. These supported features and requirements of Agile SCM include feature-oriented development, sandboxing with a private build before check-in, ability to revert to last good working version when integration testing fails, staging hierarchy, ability to revert and retarget changes, refactoring support and support for geographically distributed development.
Agile Software Development
Agile Software Development is a way of thinking about software development, as expressed in the Agile Manifesto, and acts as an ‘umbrella’ for a group of methodologies. The methodologies are based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organising, cross-functional teams. Agile software development is a conceptual framework that promotes evolutionary change throughout the entire life cycle of the project and represents a new, more flexible approach to development than the traditional methods that have been the norm for software development.
Application Lifecycle Management (ALM)
Also called ALM, Application lifecycle management is the management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.
The backlog is a prioritised list of items, often User Stories and defects, which the Development Team will convert into working product. Backlogs can include both functional, non-functional and technical team-generated stories.
Branching is the duplication of objects under revision control (such as a source code file, or a directory tree) in such a way that the newly created objects initially have the same content as the original, but can evolve independently of the original. Branching can take two forms, static or dynamic. In static branches, copy and label operations are used to duplicate a given branch. The duplicate then can evolve independently. With dynamic branches usually implemented in streams, only the label operation is used; to flag, the points in a stream diverged from its parent stream. Both branching forms support some form of merging, so that code changes made on a branch can be re-integrated into another branch, as is typical in parallel development processes.
Representation of the number of stories completed; usually represented in chart form with points plotted on an x and y-axis that map an upward trend of work completed until reaching 100%.
Representation of the number of stories completed: usually represented in chart form with points plotted on an x and y-axis that map a downward trend of work completed until reaching 100%.
Process in which changes to a product or system are introduced in a controlled manner with minimal disruptions to services and cost-effective solutions involved in implementing the changes.
Change Management enables development organisations to control, communicate and respond more effectively to rapidly changing business demands.
Change packages enable developers and managers to group file changes together into a logical whole and enable release managers to work at the issue or task level, while still providing developers with full access to the underlying file contents of the change package. Once created, a change package allows users to move, copy, modify, merge or revert the change package.
Co-location refers to development teams located and working in the same location. This is usually applied at the cross-functional team level.
Configuration Management refers to a set of practices around storing, tracking and releasing versions of a software product. Software products that enable development organisations to perform these practices efficiently are also referred to as Configuration Management systems or Configuration Management tools. Configuration Management systems will typically provide users with a variety of features, including but not limited to source code control, issue tracking and change set management.
Configuration Management Tools
Configuration Management tools are tools that make possible the practices around storing, tracking and releasing versions of the software.
Continuous Integration, one of the foundational aspects of Agile software development methodologies, as defined by Martin Fowler to be a ‘fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily, thus reducing integration problems.’ By getting changes into the mainline as frequently as possible, preferably daily, and by extending the idea of a nightly build, continuous integration helps reduce integrations problems and identify and resolve problems swifter.
A team comprised of members with all functional skills and specialities necessary to complete a project from start to finish.
Daily Stand-up/Daily Scrum
The 15 minute (maximum) daily meeting where the Scrum Team co-ordinate their activities for the next 24 hours. The meeting is purely for members of the Scrum team. It is not the time for reporting, or for any other person to ask questions.
Development teams that work on the same project but are located across multiple locations or worksites.
The adoption of specific Agile practices in an organisation that works in conjunction with other non-agile practices. Enterprise Agile is a highly efficient and customised practice for large organisations that have difficulty making a complete transition to Agile, as well as for organisations that already practice efficient development processes. Popular frameworks include NEXUS, SAFe and LeSS.
A User Story which describes a large amount of customer value and needs to be broken down into many smaller user stories.
Feature Driven Development (FDD)
Feature Driven Development (FDD) is an Agile method for developing software based on an iterative and incremental software development process.
The development process that uses both Agile and non-agile practices in conjunction with each other and is proven highly effective for development teams.
Inspecting & Adapting
Agile processes where teams evaluate a project by looking, listening to each other's feedback and ultimately improving the process or changing course.
The methodology that comes from Lean software development and has three main components: a visual system for managing work, limits work in progress and work is pulled rather than pushed through the system.
Lean Software Development
A programming concept that focuses on optimising efficiencies for development and minimising waste. According to Mary Poppendieck, 10 rules of Lean programming include:
Satisfy all stakeholders
Deliver as fast as possible
Decide as late as possible
Decide as low as possible
Deploy comprehensive testing
Learn by experimentation
Measure business impact
Optimise across organisations
Multi-stage Continuous Integration
An agile method allowing for a high degree of integration to occur in parallel while vastly reducing the scope of integration problems. Multi-stage continuous integration (CI) is an expansion upon continuous integration, where each developer works on their own task. As changes are made, CI is done against that team's branch. If CI does not succeed, then that developer (possibly with help from their teammates) fixes the branch. This way, when there is a problem, only that team, not the whole development effort is affected.
The process of incorporating branches back into the mainline.
One Piece Flow
Process in which each developer or development process works on only one piece at a time before pulling code downstream, one price at a time, to the next process.
Process in which two developers work together at a single workstation, where one is responsible for typing code and one reviews each line of code as it is typed in.
Parallel development occurs whenever a software development project requires separate development efforts on related code bases. For example, when a software product is shipped to customers, a product development team may begin working on a new major future release of the product, while a product maintenance team may work on default corrections and customer patch releases of the shipped product. Both teams begin work from the same code base, but the code necessarily diverges. Frequently the code bases used in parallel development efforts must be merged at some future date, for example, to ensure that the defect corrections provided by the product maintenance team are integrated into the major release that the product development team is working on.
A consensus-based technique for estimating; mostly used to estimate effort or relative size of tasks in software development. Planning Poker is useful for building team cohesion and fostering self-organising teams.
A Scrum role, that has been widely adopted independently of Scrum. A Product Owner is ultimately accountable for WHAT the product is. They own and order the product backlog, work with Stakeholders and Users to create Backlog Items (requirements) and guide the team with what should be done and when the final product should be shipped. The Scrum team then balances out the Product Owners decisions by deciding how much work should be involved in an individual sprint and estimating the amount of time necessary to complete the task.
The practice of continuously improving the usability maintainability, and adaptability of code without changing its behaviour. Refactoring makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code.
Release management comprises a broad set of activities in software development organisations that centre on ensuring that software is ready to be released to customers.
The software release process is the final stage in a typical software development effort, where the software product is made available for use. To ready a software product for release, the release process must ensure that all product requirements have been met, usually by executing test suites designed to exercise product functionality and correcting any defects found.
SCM tools are tools that enable organisations to perform SCM practices and typically provide users with a variety of features, including source code control, issue tracking and change set management, advanced configuration management, change packages, process management and integrated issue tracking.
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is widely used for software development but is equally applicable to solving complex problems and producing non-tech products & services. It is simple to understand and relatively difficult to implement.
A Scrum role that is key to successful adoption. A Scrum Master acts as a coach to help the Development Team optimise the value of their work. They assist the team by facilitating Scrum events, removing impediments and acting as a firewall for any unwanted distractions. The Scrum Master is a full time role and should not be confused with a Project Manager or Product Owner role.
Self Organising Team
A team, usually found in Scrum, that manages itself through various means of communication and reoccurring structured meetings. Self-organising teams solve development issues together as a whole and decide the best solution.
Software Configuration Management
Software Configuration Management (SCM), refers to a set of practices around storing, tracking and releasing versions of a software product. Software products that enable development organisations to perform these practices efficiently are also referred to as Software Configuration Management tools. SCM systems will typically provide users with a variety of features, including but not limited to source code control, issue tracking and change set management.
Software Development Process
The software development process is the set of coordinated activities performed by engineers, managers and technical writers resulting in the creation of a Software product. Various named software development processes are in use today, including Agile, XP, Scrum, Waterfall and Lean.
Source Code Control
Source code control is a common requirement in all modern software development projects that mechanisms for checking source in and out of a central repository. This allows different developers to work on the same project, with reduced fears of losing code of overwritten changes. Source code control also implies a version control system that can manage files through the development lifecycle, keeping track of which changes were made, who made them, when they were made and why. Finally, source code control also frequently involves the ability to group versioned files as a single release, maintain multiple active releases concurrently (branching), and join different releases (merging).
Source Code Management
Source code management refers broadly to the set of operations required to store, retrieve and version the files used to construct software applications. Development teams rely on source code management to organise the source code files for different releases of software so that releases can be uniquely identified for testing, packaging and delivery to customers. Failure to do this properly results in poor quality releases and inefficient use of development resources.
Time-boxed investigation of feasibility via a bare-bones implementation, which touches on all aspects of the full implementation.
A Sprint is a time-box within which work is completed - that is items from the product backlog are built and meet the definition of done. It may be anything from one week to thirty days.
Plan for the development team to map out the implementation of features for an upcoming Sprint.
A time-boxed meeting at the beginning of each Sprint when the Scrum Team agrees what they will work on during the Sprint and plan how they will do the work. A Sprint Goal is set and no further work is taken into the Sprint following Sprint Planning.
The final formal meeting at the end of every sprint to reflect on how the Scrum Team worked. The focus is on what went well, what didn't and what can be improved during the next sprint. Essential for continuous improvement, Sprint Retrospectives give Teams the necessary time to improve their efficiency, collaboration, productivity and future output.
In the Sprint Review, the Product Owner will demonstrate the work delivered to Stakeholders and Users to solicit feedback. The Scrum Team will then discuss work completed during the Sprint and how any feedback may impact their work moving forward.
The relative scale of effort required by a team to implement a User Story.
A physical or electronic board representing the state of tasks in a current sprint often divided into ‘to do’, ‘in progress’ and ‘done’.
The practice of constraining the amount of time for performing any activity. Examples include iterations, spikes and stand up meetings.
Tests that exercise small amounts of isolated functionality.
A way of conveying work to be done, specifying the problem not the solution and presented as an informal statement of the requirements (usually fitting on a 3x5 index card). Essentially, a User Story is a token for conversation between the User, Product Owner and Development Team.
The velocity of a team is the number of story points associated with stories that are finished over a given period of time, often 1 to 4 weeks. For instance, if the team completed 8 stories that were each 5 points during a four week period, then their velocity is 40 story points every 4 weeks.
Model of a software development process in which progress flows through phases of conception, initiation, analysis, design, construction, testing and maintenance
A team comprised of members with different functional skills and specialities that work together during all phases of development in order to complete a project from start to finish. Also known as a cross-functional team.
Extreme Programming (XP), one implementation of the Agile methodology that focuses on producing the simplest coding situation for application requirements and includes practices such as pair programming, incremental design and continuous integration.
So no matter where you are on your Agile journey - this glossary will be a useful resource. A common understanding of a term is critical to clarity, so discuss your understanding with your team members.