Acceptance Test

Also: Functional test, customer test

Pass/fail tests used to define whether or not a feature is functioning correctly, usually developed in parallel to the defining of the feature. These tests may be written in plain English by the customer or product owner (“The user clicks , the session is reset, and the user is redirected to the homepage”).

Ideally, an acceptance test is subsequently automated by the developer so that it can easily run on all iterations of the software, ensuring that the accepted feature has not been broken by newer development. The use of acceptance tests in subsequent iterations is also known as regression testing. Acceptance testing is a key feature of test-driven development (TDD).

Background Of The Term

The concept of acceptance testing exists in engineering disciplines other than software development and is usually referred to as black-box testing.

Although acceptance testing is common across many agile disciplines, the term derives from Extreme Programming. According to, acceptance tests were first referred to as functional tests, because they test whether or not a feature works. Kent Beck, a primary mover behind TDD, proposed the change in terminology in April 2000.

Further Learning

Acceptance Testing – Agile Alliance glossary
Acceptance testing – Wikipedia entry

Posted in a | 2 Comments


An umbrella term for iterative, incremental software development methodologies. Agile approaches include Extreme Programming (XP), Scrum, Kanban, and Lean.

Agile methodologies arose in response to traditional, phase-driven “waterfall” development methods. Those emphasize top-down project management; “big design up front”; silos for architecture and design, coding, and testing; and extensive documentation. Agile methodologies share an emphasis on small teams delivering small increments of working software with great frequency while working in close collaboration with the customer and adapting to changing requirements.

Although the agile mindset originated with software, it has since been used for non-software projects such as in manufacturing, support, and marketing. For example, see the discussion at Can You Use Agile Project Management for Non-Software Projects

Background Of The Term

The term “agile” was first used by a group of software pundits who gathered at a ski lodge in Snowbird, Utah for the express purpose of naming and defining the greater movement in which they deemed themselves to all be participants. The original invitation to Snowbird went out to those interested in “lightweight” development frameworks. The attendees agreed that they didn’t like the negative connotations of “lightweight”, instead adopting the term “agile.”

Out of that meeting came the Agile Manifesto.

Further Learning

History: The Agile Manifesto – a little historical background on the manifesto and reflection on agility as recounted by Jim Highsmith, one of the signatories.

What Is Agile Product Management: Guide To Processes & Roles – blog post by Michael Luchen

What is Agile? – blog post from Atlassian

Posted in a | 4 Comments


In general a backlog is a set of items of work to be done or that might be done. A work item may be a change to an existing product feature, a new feature, a fix for a defect, a change in the environment that the product runs under, or any other activity that may contribute to its value such as a refactoring of software.

In the scrum framework and other agile approaches, a product backlog or release backlog is ever-evolving and continuously updated. It is the single source from which work items are discussed, refined, selected, and committed to. Backlog items may be at different levels of detail, some with sufficient detail that they are ready to be implemented, others with a general description that will need further refinement. Backlog items may use different formats such as user stories.

A backlog item may include its business value as provided by the customer. It may include a size that is an estimate of the amount of effort to implement it. A backlog may have its items sequenced into an ordering in which they are to be implemented, where the order is determined by considering business value and size along with other factors such as dependencies.

In addition to the product backlog, an agile team typically creates a backlog specifically for each development iteration, known as an iteration backlog or sprint backlog. The items in a sprint backlog are drawn from the product backlog. Those items should be considered sprint ready.

Further Learning

Product Backlog – Agile Alliance glossary
Sprint Backlog – Agile Alliance glossary

The 2020 Scrum Guide – Product Backlog – Ken Schwaber and Jeff Sutherland
The 2020 Scrum Guide – Sprint Backlog – Ken Schwaber and Jeff Sutherland

Agile Product Backlog with User Story Mapping – Video, 9 minutes
Product Backlog Management: What NOT to do – Video, 6 minutes

Posted in b | 2 Comments

Backlog Refinement

Backlog refinement is the process of adding new user stories to the backlog, re-sequencing existing stories as needed, creating estimates of effort for previously un-estimated stories, and decomposing large stories into smaller stories or tasks.

Backlog refinement is both an ongoing process as well as more specifically the event or ceremony that occurs regularly within a team’s iteration cycle to accomplish the above.

Scrum trainer and consultant Roman Pilcher explains the significance of backlog refinement to the agile development process: “Grooming the product backlog collaboratively creates a dialogue within the scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies.” It eliminates wasteful handoffs, and avoids miscommunication and misalignment. Requirements are no longer handed off to the team; the team members co-author them. This increases the clarity of the requirements, leverages the scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.”[1]

Scrum Alliance founder Ken Schwaber recommends that teams allocate 5% of their time to revisiting and tending to the backlog.

Background Of The Term

This was originally called “backlog grooming” but was changed in 2013 due to the current negative connotation of “grooming”. See Child Grooming.

The ceremony is also known as “backlog maintenance” and “story time“.

Further Learning

Backlog Refinement – Agile Alliance glossary
Daddy, Where Do Product Backlog Items Come From? – Agile Learning Labs – blog post
What NOT to do during Product Backlog Refinement? – Serious Scrum – blog post


Posted in b | Leave a comment

Big Visible Charts

See Information Radiator.

Posted in b | Leave a comment

Burndown Chart

Burndown charts plot units of work that remain to accomplish (y-axis) against units of time (x-axis). In scrum the burndown chart is commonly used to track and forecast progress.

Release Burndown

Release Burndown Chart

The units of work that appear on a burndown chart are derived from items in the release or product backlog. During the process of backlog refinement items are assigned an estimated point value that is a measure of effort (also known as “story points” or “size”).

The trend line on a release burndown chart will generally trend downward. However, if new items are added to the release backlog, then the total points remaining may go up.

The release burndown chart is the primary tool a team has for visualizing their “velocity”, which is the average number of points they accomplish during an iteration.

Iteration / Sprint Burndown

The initial point value of work remaining in a sprint burndown chart derives from the backlog items the team commits to during the sprint. Work remaining is generally graphed daily. The number of points the team undertakes is based on their established team velocity, i.e., the number of points they routinely have completed historically.

In scrum, no new work may be added once a sprint has begun, so the trend line will never rise. However, in Extreme Programming, work may be added during a sprint, so the trend line may rise.

Further Learning

Burndown Chart – Agile Alliance glossary

Posted in b | Leave a comment

Cognitive Bias

A cognitive bias is a systematic pattern of irrationality. Cognitive biases can lead to perceptual distortion, inaccurate thinking, illogical interpretation, and poor decisions. Because cognitive biases affect how people understand and even perceive reality, they are difficult to avoid, even once a person becomes aware of them. Virtually everyone’s thinking is degraded by cognitive biases.

Further Learning

Posted in c | Leave a comment

Component Team

A component team is a team that is specialized to work on a single part of a larger system.

A common scenario would be a website that has back-end code that runs on the server and front-end code that runs in the web browser. The back-end might be coded in Java and the front-end might be coded in HTML and Javascript. One component team, staffed by Java developers, might do all work on the back-end. Another component team, staffed with HTML and Javascript developers, would do all work on the front-end.

An advantage of component teams, compared to feature teams, is that it is easier to maintain consistent architectural and coding standards in each part of the system, since only one team works on each component. A disadvantage is that most customer-facing features will require work from multiple component teams in order for the overall feature to be completed. Thus, organizations with component teams tend to have more cross-team dependencies than those with feature teams.

Posted in c | Leave a comment


See Product Owner.

Posted in c | Leave a comment

Customer Test

See Acceptance Test.

Posted in c | Leave a comment