Development Team

The team comprises all the individuals involved in the delivery of the software. This includes but is not limited to project managers, business analysts, user interface designers, software engineers and testers.


Product Backlog

A prioritised list of product backlog items and bugs that describes the functionality to be developed during the project and hence the scope of the software deliverable.

Keeping the product backlog up to date is the responsibility of the product owner and it is reviewed, validate and updated by the development team during product backlog refinement sessions.

Product Backlog Item

A unit of testable functionality, usually expressed as a user story with acceptance criteria.  Each product backlog item represents a unit of testable functionality, not a technical task.  The effort estimated to complete a product backlog item is represented in ideal man days of effort.

By default the description should be a user story of the form: as a [user] i want to [do something] so that [awsome things happen]

Be default exepctance criteria should be: given [staring condition] when [i do something] then [something happens]


A defect that has been logged against development work that has been completed.  This should contain reproduction steps as well as an indication of the severity of the defect.

Definition of Done

A statement that describes what needs to be completed for a product backlog item to be considered done.  This is used in the estimation of product backlog items to understand what is involved in their delivery. This can include product owner sign-off, manual test passed, automated test in place, technical documentation updated, end user documentation updated, etc.

definition of

Product Owner

The product owner is responsible for maintaining an accurate product backlog and ensuring that it reflects the priorities of the product stakeholders.

The product owner is also responsible for demonstrating the current product increment during the sprint review meeting held with stakeholders.

Sprint Review Meeting

A meeting held at the end of each sprint with the development team and the stakeholders to demonstrate the latest product increment and gather feedback on the work completed.

Product Increment

A working version of the software that is produced at the end of each sprint and contains the implemented features described by the product backlog items in the sprint.

Ideal Man Days

What you could get done in a darkened room with no interruptions and nothing else to do in one day.  A team’s velocity is not the sum of the ideal man days available in the sprint.


The total effort removed from the remaining product backlog due to completing product backlog items in a sprint.


A two-week iteration of development containing product backlog items to be delivered along with their associated tasks.


The technical work required to implement part of a product backlog item.  The effort estimated to complete a task is represented in hours’ work.

Planning Poker

A method of generating estimates where each team member selects a card with the value which they believe represents the effort involved.  The team all reveal the card they have selected at the same time and if there is a large discrepancy between two or more of the estimates a conversation is needed to understand why and then estimate again.

Planning poker cards

Scrum cards are used in Planning Poker to estimate work