Agile Terminologies and Definitions
Acceptance Testing
Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.
Agile Software Development Methodology
Agile software development puts a heavy emphasis on collaboration, responsiveness to change, and the reduction of waste throughout the development cycle. Agile software development focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they’re ready.
An important agile principle is to deliver (potentially) releasable software after every iteration.
Backlog Grooming
Backlog grooming is the process of adding new user stories to the backlog, re-prioritizing existing stories as needed, creating estimates, and deconstructing larger stories into smaller stories or tasks. Rather than grooming the backlog sporadically throughout an iteration, the team may hold a backlog grooming session once per iteration.
Breaking the Build
When a developer adds changes to the source code repository that result in the failure of a subsequent build process, the developer has “broken the build.”
It should be a team commitment to avoid breaking the build as it will slow down the development and can be a bottleneck for other developers. When the build is broken, the development team is to take immediate action to fix the build.
The build is broken if the build process cannot be successfully completed for any number of reasons including (but not limited to) failure to compile, compiling with unacceptable warnings, or the failure of any number of automated tests.
Build Process / Build Pipeline
The build process or build pipeline, is the process in which a story goes from inception to production, usually going through different stages and checks to ensure quality.
The build pipeline defines the workflow for software delivery and what happens at each stage.
Burndown Chart
A graph that displays the total task hours remaining per day. It shows where the team stands regarding completing the tasks that have been committed to the sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining.
Chicken
In scrum, chicken is a slang word used for someone who is interested in a project but has no responsibility for working on a task in the active iteration. They may observe team meetings but cannot vote or talk.
Continuous Integration
Continuous Integration (CI) is an eXtreme Programming (XP) practice where members of a delivery team frequently integrate their work (e.g. hourly, or at least once daily).
Each integration is verified by an automated build, which also performs testing, to detect any integration errors quickly and automatically. The main goal of CI is to avoid what is commonly called integration or merge hell.
Cross-Functional Team
Team comprised of members with all functional skills and specialties (often called multi-skilled) necessary to complete a project from start to finish.
Customer
Customer is normally defined as the recipient or user of the product. Customers may be internal or external to the organization. The customer may be one person, a department, or a large group.
Internal customers are sometimes called the “Business.”
Daily Standup
A daily team meeting usually held first thing in the morning to provide a status update to the team members. The meetings are usually time-boxed to 5-15 minutes, and are held standing up to remind people to keep the meeting short and to the point.
Definition of Done (DoD)
The criteria for accepting work as completed. Specifying these criteria is the responsibility of the entire team, including the business. Generally, there are three levels of “Done” (also known as Done-Done-Done):
- Done: Developed, runs on developer’s box
- Done: Verified by running unit tests, code review, etc.
- Done: Validated as being of deliverable quality with functional tests, reviews, etc.
The exact criteria for what constitutes “Done” varies to meet the specific needs of different organizations and initiatives.
Epic
A very large user story that is eventually broken down into smaller stories. Epics are often used as placeholders for new ideas and related stories to be developed in subsequent sprints.
Epic stories help Agile development teams effectively manage and groom their product backlog.
Estimation
The process of agreeing on a size measurement for the stories or tasks in a product backlog. On agile projects, estimation is done by the team responsible for delivering the work, usually using a planning game or planning poker.
Extreme Programming
An agile software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.
XP advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Other elements of extreme programming include: pair programming, extensive code reviews, unit testing, Continuous Integration to name a few.
Feature
A coherent business function or attribute of a software product or system. Features normally comprise many detailed (unit) requirements. A single feature is typically implemented through many stories.
Features may be functional or non-functional; they provide the basis for organizing stories.
Fibonacci Sequence
A sequence of numbers in which the next number is derived by adding together the previous two (e.g. 1, 2, 3, 5, 8, 13, 21, 34…). The sequence is used to size stories in Agile estimation techniques such as planning poker.
Impediment
Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily standup meeting.
The ScrumMaster’s job is to ensure impediments are removed as soon as possible so the team can continue to be productive.
Iteration
A period (from 1 week to 2 months in duration) during which the Agile development team produces an increment of completed software. All system lifecycle phases (requirements, design, code, and test) must be completed during the iteration and then demonstrated for the iteration to be accepted as successfully completed.
At the beginning of the iteration, the business or the product owner identifies the next (highest priority) chunk of work for the team to complete. The development team then estimates the level of effort and commits to completing a segment of work during the iteration.
Kanban
Kanban is a tool derived from lean manufacturing and is associated with the branch of agile practices loosely referred to as Lean Software Development. Kanban constrains how much work in progress is permitted to occur at the same time.
The main difference between Kanban and Scrum is that Scrum limits work in progress through sprints and Kanban limits work in progress by limiting how much work may occur at one time (e.g. N tasks or N stories).
Lean Software Development
Lean software development or just Lean is focused on reducing waste and optimizing the software production value stream.
Minimum Viable Product (MVP)
The smallest working product that can be built and tested and delivered in a given time that provides value to users.
Pair Programming
An agile software development technique in which two programmers work together at one workstation. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. and the person reviewing the code is called the observer or navigator. The two programmers switch roles frequently.
Pig
Someone who is responsible for doing a task on an active iteration. It is the opposite to Chicken. Pigs are actively involved in the project.
Planning Poker
Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development. The team use the fibonacci series or T-shirt sizing to estimate stories during the planning poker game.
Product
Broadly speaking, product refers to a collection of features that are integrated and packaged into software releases that offer value to a customer or to a market.
Product Owner
Product Owner is one of the key roles in Scrum. The responsibilities of the Product Owner include:
- Establishing, nurturing, and communicating the product vision
- Creating and leading a team of developers to best provide value to the customer
- Monitoring the project against its ROI goals and an investment vision
- Making decisions about when to create an official release
Product Backlog
Product backlog is like a wish list of features that business want to deliver in the long term. It is a collection of stories and tasks the team will work on at some point in the future.
The Product Owner maintains this list of product backlog in accordance to business priorities and needs. The items in the backlog should reflect the business roadmap.
Refactoring
Changing existing software code in order to improve the overall design. Refactoring normally doesn’t change the observable behavior of the software; it improves its internal structure.
Release Plan
The release plan is a schedule for releasing software into production. Typical release plans include the key features to be delivered, along with corresponding release dates.
Retrospective
A timeboxed meeting held at the end of the sprint in which the team examines its processes to determine what succeeded and what could be improved. The retrospective is key to continuous improvement.
A positive outcome for a retrospective is to identify one or two high-priority action items the team wants to work on in the next iteration or release.
Scrum
Scrum is a framework for developing complex software products in an iterative and incremental fashion and is the most widely recognized Agile framework.
Scrum is comprised of a series of short iterations – called sprints – each of which ends with the delivery of an increment of working software.
Scrum Team
The scrum team is a cross-functional and self-organizing group that is responsible for delivering the software.
The scrum team includes multi-skilled people who understand customer requirements and conduct software design, coding and testing. Additional skills (e.g. UI design, usability, etc.) may also be included.
The scrum team is responsible for all work commitments and outcomes.
ScrumMaster
The ScrumMaster is responsible for maintaining the Scrum process and the overall health of the team. The ScrumMaster assures that the team is fully functional and productive by removing any obstacles that may be impeding the team’s progress. The ScrumMaster also organizes the Scrum ceremonies.
Spike
A story or task aimed at answering a question or gathering information, rather than implementing product features, user stories, or requirements.
Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is a story whose purpose is to provide the answer or solution.
Sprint
In product development, a sprint is a set period of time during which specific work has to be completed and made ready for review. A typical sprint length is usually 2 weeks and normally not any longer than 4 weeks.
Sprint Backlog
A list of features, user stories or tasks that are pulled from the product backlog for consideration for completion during the upcoming sprint. Product backlog features and user stories are broken down into tasks to form the sprint backlog during the sprint planning meeting.
Story Grooming
In story grooming sessions, the details of user stories are fleshed out. Acceptance Criteria are written and elaborated. Stories are also estimated at this stage.
The aim of this session is to ensure that everyone who is involved in developing and testing the stories share a common understanding of the context of the stories before beginning development of the stories.
Story grooming sessions are usually held mid-sprint for the following sprint so that the team are aware of the workload for the next sprint.
Participants are the scrum team, scrum master and the product owner.
Sprint Planning
Sprint planning sessions are held just before the start of a new sprint. In this session the team identify the tasks that needs to be done and decide how many story points they can commit to for the upcoming sprint.
Before sprint planning sessions, the stories should have been elaborated and estimated during the Story Grooming sessions, so that no time is wasted during sprint planning.
Participants are scrum master and the scrum team.
User Story
A User Story (a.k.a Story) can be thought of as a requirement, feature which has some business value.
Stories describe the work that must be completed to deliver a feature for a product. Stories are the basic unit of communication, planning, and negotiation between the Scrum Team, Business Owners and the Product Owner.
Stories consist of the following elements:
- A description, usually in business terms
- A size, for rough estimation purposes, generally expressed in story points (such as 1, 2, 3, 5)
- One or more Acceptance Criteria, giving a short description of how the story will be validated
Task
Tasks are descriptions of the actual work that an individual or pair does in order to complete a story. They are manageable, doable, and trackable units of work. Typically, there are several tasks per story.
Technical Debt
A term coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.
T-Shirt Sizing
A method of estimating the work needed to complete a story in T-shirt sizes, i.e. Small (S), Medium (M), Large (L) or X-Large (XL)
Timebox
A timebox is a time period of fixed length allocated to achieve some objective. In agile development, iterations and sprints are examples of timeboxes that limit work in process and stage incremental progress.
Velocity
Velocity measures how much work a team can complete in an iteration. Velocity is often measured in stories or story points. Velocity may also measure tasks in hours or an equivalent unit.
Velocity is used to measure how long it will take a particular team to deliver future outcomes by extrapolating on the basis of its prior performance.
Work In Progress
Any work that has not been completed but that has already incurred a capital cost to the organization. Any software that has been developed but not deployed to production can be considered a work in progress.