Agile Dictionary


  1. Find out where you are
  2. Take a small step towards your goal (and if there are multiple choices here, take the path of least regret, or the one that makes future change easier)
  3. Adjust your understanding based on what you learned
  4. Repeat

Dave Thomas


If there is an aspect in the sprint, be it functional or technical, which is unclear, a spike can be the solution. It has as goal to clear out the aspect. The spike can be triggered by a user story that cannot be estimated because of certain aspects we do not know of as a team.

 For instance the user story requires a certain technological knowledge which the team lacks, so we need to investigate this aspect. Another example could be that we need to create a report on the project data and by starting the user story we discover some issues in the data quality or data is not properly normalized.

A spike is always time boxed.


This technique can be used to find out the team’s opinion on a certain issue. In stead of saying yes or no, this method allows for gradients of agreement.

Hands should come up simultaneously. You can also allow for a sixth option: closed fist! See for a good explanation.


A user story should adhere to the following features:

  • Independent: can be tested and developed individually
  • Negotiable: can be discussed in detail later
  • Valuable: have business value
  • Estimable: allows for an initial estimate
  • Small/Slice-able: smaller is more easy to understand; can be divided up into tasks that can be implemented independently
  • Testable: if you cannot test it it is not clear

Definition of Done

Before the sprint review meeting, all sprint backlog items should adhere to a set of agreements so the PO can accept the product backlog item as finished. These agreements are mostly non-technical and will grow overtime. You can even start with “Product owner has to agree that the feature is done“. 


  • Fully tested (unit, integration, regression tested)
  • Adheres to the business acceptance criteria
  • Peer reviewed
  • Adhere to programming standards
  • Deployed in User Acceptance environment
  • Adhere to certain specific external regulations
  • Adhere to the non-functional requirements (performance, user experience, security …)

Definition of Ready

Before the sprint planning takes place, the product backlog items that are intended for the next sprint should adhere to the INVEST principle and have enough detail, so the team can start estimating it in the sprint planning. It is the responsibility of the PO to make the PB items ready, which does not mean (s)he has to do this on her own . In agile terms  “enough detail” does not mean that all details should be available before the next sprint: enough details to do a proper estimate but not too much detail to ensure team swarming and gradual insight are not nipped in the but.

“My advice is that teams should identify about two-thirds of a sprint’s tasks during sprint planning. That means one-third of the tasks that will be done during the sprint will be left to be identified during the sprint. ” ~ Mike Cohn

Agile Manifesto

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

See Agile Manifesto.

Burn-down chart

This chart shows per sprint the amount of work being performed compared to the planned amount of work. From this chart you can derive the velocity of the team.

Burn-down chart

Burn-up chart

A burn-up chart allows you to predict when a certain amount of work will be ready, be it a release, a certain user story or the project completion. You need the following to create a burn-up chart:

  • A prioritized product backlog
  • Each user story that is part of the goal you want to predict should be estimated
  • The average, lowest and highest velocity (derived from realistic burn-down sprint charts


You can also use a burn-up chart to measure the work planned against the actual work. It allows you to see if the project scope was changed during the project.



It measures the amount of work performed by the team during a sprint. The velocity will change over time since it is measured after each sprint but should stabilize after a while.

An optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team. (source: the Scrum Glossary)

Note that the 3 first sprints, your velocity will be unpredictable since the team has to settle with the infrastructure and the requirements, and is not yet working on normal speed. Unless you have historical velocity data from the same team on previous projects.

Daily Scrum

What is the Daily Scrum for?


Originally this was a scheduling system at Toyota manufacturing, introduced after the second World War. To avoid keeping too much raw materials in stock for the production line and to deliver cars Just In Time, Kanban uses a pull mechanism to streamline the needs of their customers with the Just In Time delivery of raw materials by the supplier. The need of a certain raw material on the supply chain is visualised by using “signboards”. The consumption of cars drives the production and thus the delivery of raw materials from stock or from the supplier. Advantages are:

  • Stock is kept at a minimum
  • Faster turnaround in production
  • Becoming more competitive

In the IT world this approach is used to visualise all work items (also non tangible), showing the progress of all the work items. Team members pull work as they have the capacity to do so. It helps to see what, when and how much to produce. Another important feature is too limit the work at some or each state of the development workflow. In Scrum projects you freeze the work for the entire sprint. In Kanban you can limit the number of items you are analysing, developing, testing, releasing. Keeping the team focused is important: multi-tasking generates overhead to switch between tasks. It is also better to finish 3 user stories than to almost finish 12 stories. You can put these limits if you encounter a bottleneck in the work in progress. For instance if you have only 1 tester and multiple developers (s)he might be overbooked and the pipeline will get stuck. You can address this by limiting the number of items being tested. Or you can encourage developers to help in testing. Analysing too much items up-front is also a bad habit, so you can put a limit on it as well.

It can also be applied outside of developing software when the work is intangible or tends to operational work. Some of the most important principles are:

  • Start with what you know now
  • Learn by doing
  • Engage all people involved
  • Focus on the customer’s needs
  • Self-organising teams
  • Visualise and Transparency
  • Allow for feedback loops
  • Limit the work in progress per state