Agile Termilogy

Acceptance criteria

These are specific criteria identified by the customer for each functional requirement. The acceptance criteria are written in simple terms and from a perspective of the customer. 

Sample format is: 

As a.....I want to..... so that I can......

Acceptance testing

Acceptance testing is a validation activity conducted to determine whether or not a system satisfies its acceptance criteria. It is the last phase of the software testing process.

Agile

A conceptual framework for undertaking software projects. Agile methods are a family of development processes, not a single approach to software development.

Behavior Driven Development

Behavior driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read. 

Bottleneck

A bottleneck is a sort of congestion in a system that occurs when workload arrives at a given point more quickly than that point can handle it. 

It is metaphorically derived from the flowing of water through a narrow mouthed bottle where the flow of water is constrained by the size of its neck.

Bugs

A software bug is a problem causing a program to crash or produce invalid output. It is caused by insufficient or erroneous logic and can be an error, mistake, defect or fault.

Burndown Chart

A burndown chart is a visual tool for measuring and displaying progress. Visually, a burndown chart is simply a line chart representing remaining work over time. Burndown charts are used to measure the progress of an agile project at both a iteration and project level.

Daily Standup/Scrum

A Daily Standup is a whole team meeting that happens at the same time every day that usually lasts 15 minutes or less. The meeting is designed to allow the entire team to synchronize with each other and to understand the flow and challenges of the development process. Each team member should provide the following information: what did I do yesterday, what am I planning to do today, and what impediments do I currently have?

Done

Also referred to as “Done Done”, this term is used to describe all the various tasks that need to happen before a story is considered potentially releasable.

Epic

A very large user story that is eventually broken down into smaller stories.

Estimation

The process of agreeing on a size measurement for the stories, as well as the tasks required to implement those stories, in a product backlog.

Feature creep

Feature creep occurs when a software becomes complicated and difficult to use as a result of too many features.

Kanban

Kanban, pronounced /ˈkɑnˈbɑn/, is a method for developing products with an emphasis on just-in-time delivery and the optimization of flow of work on the team. It emphasizes that developers pull work from a queue, and the process, from definition of a task to its delivery to the customer, is displayed for participants to see.

Lean

Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. Adapted from the Toyota Production System and is a set of techniques and principles for delivering more values with the same or less resources by eliminating waste across organizations and business processes

Pair Programming

Pair programming is 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. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently.

Planning Poker

Also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development.

Product Backlog

Acts as a repository for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders. The requirements are listed on the backlog in priority order and maintained by the product owner.

Product Owner

The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner.

Retrospective

A team meeting that happens at the end of every development iteration to review lessons learned and to discuss how the team can be more efficient in the future. It is based on the principles of applying the learning from the previous sprint to the upcoming sprint.

Scrum

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. It is based on the adaptive and iterative methodology of software development.

Scrumban

Scrumban is a mix between Scrum and Kanban, which supposedly contains the best features of both methods.

Scrum Master

Scrum is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the team leader but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks at hand. The role has also been referred to as servant-leader to reinforce these dual perspectives.

Spike

A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the story.

Sprint / Iteration

A fixed duration period of time where user stories are chosen to work on. The term Sprint comes from the Scrum methodology and is analogous to the term Iteration. A sprint is defined as a 2-4 week increment of software development activities that delivers working software and the end of the increment. External influences are not allowed to change the requirements of the stories being worked on.

Sprint Backlog

At the beginning of each sprint, the team has sprint planning with an end result being a backlog of work that the team anticipates completing at the end of the sprint. These are the items that the team will deliver against throughout the duration of the sprint.

Sprint Planning

Is a pre-sprint planning meeting attended by the core agile team. During the meeting the Product Owner describes the highest priority features to the team as described on the product backlog. The team then agrees on the number of features they can accomplish in the sprint and plans out the tasks required to achieve delivery of those features. The planning group works the features into User Stories and assigns Acceptance criteria to each story.

Sprint Review

Each Sprint is followed by a Sprint review. During this review the software developed in the previous Sprint is reviewed and if necessary new backlog items are added.

Story Points

Unit of estimation measuring complexity and size.

Task

A user story can be broken down in to one or more tasks. Tasks are estimated daily in hours (or story points) remaining by the developer working on them.

Taskboard / Storyborad

A wall chart with cards and sticky notes that represents all the work for in a given sprint. The notes are moved across the board to show progress.

Team

The Team is responsible for delivering the product. A Team is typically made up of 5–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). It is recommended that the Team be self-organizing and self-led, but often work with some form of project or team management.

Test Driven Development

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.

Timeboxing

Timeboxing is a planning technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget.

User Persona

Personas are a description of the typical users of a given software. A persona description should include:

1) Skills and background – E.g. professional or beginner computer user
2) Goals – E.g. what does the user expect from the product?

User Story

A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. A user story is also a placeholder for conversation between the users and the team. The user stories should be written by or for the customers for a software project and are their main instrument to influence the development of the software. User stories could also be written by developers to express non-functional requirements (security, performance, quality, etc.)

Velocity

It is a relative number which describes how much work the team can get done over a period of time.

Vertical Slice

Showing off a feature in an application that works from start to finish but may be limited in scope. For example a rope bridge crossing a chasm is immediately useful and allows people to cross. Having that in place can help to build a better bridge later.

WIP

Also known as Work in Progress is any work that has been started but has yet to be completed.

XP

A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.