Home » Toolkit » Glossary of Terms

Glossary of Terms


Agile is a way of working. It is a business-focussed mindset (based on the Agile principles) coupled with a suite of practical tools (the Agile practices). An Agile way of working enables individuals, teams and organisations to consistently deliver fast, customer-centred outcomes with reduced risk at a lower cost, whilst remaining responsive to changing environments.

Agile 2.0 (agile next generation)

The next generation of agile practices are still based on the established Agile principles. The evolution is concerned with improving the regularity, low-risk, high-velocity, and sustainable pace of delivering business value.

Advanced Agile teams that have developed a high level of Agile maturity are often disbanded as their projects are handed over BaU. Agile 2.0 seeks to break this cycle by creating perpetual delivery teams and abandoning the concept of Project versus BaU. A major benefit of this mode of work is that "the team that builds it, supports it", eliminating some of the poor practices where projects are "lobbed over the fence" with minimal or ineffective handovers.

Such a perpetual team can be smaller in size than traditional project teams, but can help minimise change impacts by delivering smaller changes with a more regular frequency at a lower unit cost. Many other advanced Agile techniques can be incorporated into a next-generation Agile team, however such a team must be highly competent at all of the Agile practices before contemplating such a transition.

Human Resource professionals will be required to assist with organisational and job design elements as people’s roles will evolve from temporary project assignments to a more permanent project and support responsibilities within a cross-functional team. Often members of these teams require multiple leaders within a matrix structure to satisfy their functional skills (e.g. as a Procurement expert) as well as the priorities and expectations of a business sponsor or project management office.

Agile Manifesto

In February of 2001, 17 respected, independent thinkers from various software development schools of thought, got together to re-invent software development. Taking it from a heavy, documentation-driven process, they used a principle-based approach to conceive the Agile Software Development Manifesto (http://agilemanifesto.org).

Agiledirect has used this manifesto to uncover better ways of delivering business outcomes by running Agile projects and helping others to do so. Through this work we have come to value:

  • Conversation over documentation
  • High performing team over a team of high performers
  • Clarity over certainty
  • Course correction over planning perfection
  • Outcomes over comprehensive documentation
  • Sufficient quality rather than over-elaborate solutions
  • Bad news delivered early over good news delivered late

That is, while there is value in the items on the right, we value the items on the left more.

Agile Practices
A series of tools, techniques and processes that are underpinned by the Agile principles. The primary practices include:
Agile Principles

The original Agile principles (written for software development) are outlined in the Agile Manifesto. Agiledirect has considered the benefits of the original manifesto’s principles and re-imagined them for application in today’s business environment. This is useful for a wide range of business projects and BaU activity.

Agile Principles (Agiledirect adjusted):

  1. Focus on value: The highest priority should be to satisfy the customer through early and continuous delivery of business value. No one can know everything at the beginning of a project (referred to as the ‘illusion of certainty’). Only when work has started can we become more certain of the time, cost and quality requirements.
  2. Embrace change: We welcome changing requirements, even late in the project. Agile processes harness change for the customer's advantage. It is the customer that possesses agility in an Agile project as they can change direction with minimal risk and cost impacts.
  3. Get on with it: Deliver working outcomes frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. This lets the customer see the effect of the changes early and avoids significant rework found in traditional project methodologies.
  4. Daily collaboration: Business people and project teams must work together daily throughout the project.
  5. Engaged and enabled people: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. A cross-functional autonomous team is best equipped to leverage "wisdom of the crowd" to solve problems in ingenious and cost-effective ways.
  6. Optimal communication: The most efficient and effective method of conveying information to and within a team is face-to-face conversation.
  7. Focus on outcomes: Working outcomes are the primary measure of progress. Measurement of activities ignores the progress towards business value at the expense of micro-managing a team
  8. Sustainable cadence: Agile processes promote a sustainable delivery cadence. The extended project team should be able to maintain a constant pace indefinitely. See Agile 2.0 for examples of how to take a mature agile team to the next level of self-organising productivity.
  9. Focus on the things that matter: Attention to excellence and good design enhances agility.
  10. Simplicity and sufficiency: The art of maximising the amount of work not done.
  11. Use the wisdom of the crowd: The best ideas, understanding of requirements, and designs emerge from self-organising teams
  12. Continuous improvement: At regular intervals, the team pauses to reflect on how to become more effective, then tunes and adjusts its behaviour accordingly. The team is transparent in delivering bad news early and ensuring course corrections are deliberate and beneficial.
Agile Project Management

The label given to collection of Agile Principles and Agile Practices when applied to running a project.

Agile Wall

Is a visual approach to displaying work and is a significant artefact in an Agile way of working. An Agile Wall is typically applied to an actual piece of vertical real estate (but could also be a portable board or online tool) and represents the work "to do", "in progress", and "done". An individual or team uses the wall as an interactive aid to visualise work. Often, library cards or post-it notes are affixed to the wall and manipulated as required to manage the work.

An Agile Wall typically includes elements such as scope, deliverables, milestones, release plan, story cards, task cards and a RIO (risks, issues and opportunities). To maximise the value of an Agile Wall, a team will conduct stand-up meetings in front of the wall and manage the cards according to the work being carried out.

An Agile Wall can also be referred to as a story wall, storyboard, task wall, Kanban board, task board, or project wall.

Business stakeholders from the extended team are encouraged to "walk the wall" to obtain near real-time status updates on the teams progress, supplementing the need to rely solely on status reports.


A business object that represents something of tangible value. Important Agile artefacts are:

Often, these key artefacts are managed on an Agile Wall.


A collection of stories and tasks that represent the project scope. A team represents what they will work on at some point in the future using a Backlog. Backlog cards are usually tracked on a real and/or electronic Agile Wall.

Backlog Grooming

A regular process (part of a team’s cadence) that involves adding new tasks / stories to the backlog, re-prioritising existing work or removing redundant scope. Stakeholders from the extended team (e.g. Sponsor, Product Owner) are encouraged to attend and participate in these sessions to ensure the scope (i.e. the backlog), remains aligned to their desired business objectives


See Business As Usual.

Benefits Map

A visual representation of how activity is linked to the generation of desirable outcomes. These desirable outcomes are ideally well quantified or qualified as either tangible or intangible benefits. The team’s project charter should contain this benefits illustration showing how the goals and objectives of the project will link to the benefits. Further mapping can then occur to map specific features or groups of features to particular benefits. This exercise usually creates the fist release plan as each incremental release should deliver or significantly contribute to the stated benefits.

Big Visual Chart (BVC)

Encompasses a range of different types of visualisations that are …big and visual. The intent of BVCs are to 'radiate' information in such a way that an audience can clearly, quickly and succinctly receive it. The most common example of a BVC is the Agile wall itself. The Agile wall serves as a medium during a stand-up meeting to track the work to do, in progress and done. The Agile wall is also a powerful BVC to actively manage risks, issues and opportunities (RIO).


Any resource or process whose capacity is less than or equal to the demand placed on it, thus constraining the flow of work or information through a process and therefore (usually undesirably) impacting upstream and downstream processes. The core team often calls upon members of the extended team to remove or resolve these bottlenecks. Most take the form of people or roles outside of the project that insist on involvement or approval requests funnelling through them. The agile approach of transparency should be used to bring such people closer to the project and involve them in relevant agile practices to meet their needs, as opposed to completing additional artefacts to suit that purpose. In this sense, the Agile way of working is often seen as a source of disruptive innovation and should be embraced as a catalyst for efficient change.

For those external processes that add value and ensure good governance practices are maintained (e.g. Risk, Fraud, Audit), then every effort should be made to include these processes in the release plan and the team’s cadence.

Burn Down Chart

A visual representation of the amount of work remaining in a Timebox (or Iteration) that decreases cumulatively across time boxes. The burn down chart typically plots a line that reduces in scale based on the work remaining to reach a given goal (on the vertical axis) across time (on the horizontal axis). A more detailed explanation can be found here.

Burn Up Chart

A visual representation of the amount of activity completed in a Time box (iteration) that is cumulatively increases across time boxes, usually the entire project’s duration. This resulting line maps an upward trend from left to right across the chart. Also plotted on the chart is a line representing the amount of work planned (referred to as ‘the scope line’). The distance between the two lines is thus the amount of work remaining. When the two lines meet the project is typically considered complete. The benefit of a burn up chart over a burn down chart is the inclusion of the scope line as it clearly indicates when work has been added or removed from the project. A burn up chart is similar to an earned value chart. A more detailed explanation can be found here.

Business as Usual (BaU)

The typical course of activity that an individual or organisation undertakes to deliver its core products and / or services. This is true even during circumstances that are ‘out of the ordinary’ business operations (e.g. doing disaster management in accordance with a business continuity plan).

BaU also relates to the normal execution of standard operations within an organisation. This is in contrast to the execution of a project that will likely introduce change, although that change may eventually become BaU. BaU processes are managed via already established organisational structures whereas projects are managed by bespoke governance structures such as steering committees extended teams and core teams.

Although BaU activity is typically predictable and cyclical in nature, it may be managed using the principles and practices associated with project management. Some examples of BaU activity that may adopt a project management approach are organisational real estate changes, system upgrades, disaster management and audit management.

Another term sometimes used to describe BaU is 'lights-on' (generally for Information Technology functions). Lights-on usually refers to the work required to keep business systems up and running.

Business Benefits

Benefits are the tangible and / or intangible positive changes that an organisation can expect to receive through the achievement of objectives. These objectives can be completed as part of Business as Usual (BAU) or as part of a project. Often, the likelihood of achieving a benefit is used to justify the initiation and resourcing of a project.

The linkage between benefits and the work to be done to achieve the benefit should be shown in a benefits map. The benefits map should trace the relationship between the project’s goals, to its features, through to its minimal marketable features (MMFs). These MMFs, once released, will deliver specific benefits that should be quantified where possible.

An assessment of business benefit should be a key element in any business case and also a key feature to guide the execution of the project plan. In their simplest form, benefits can be defined by evaluating the trade-off between cost and return. This may be measured and quantified financially (e.g. ‘cost-benefit analysis’). For intangible benefits such as improved staff morale, there are often organisational measures that can be used such as ‘% employee engagement’. Consider a range of metrics before defaulting to a completely subjective measure of benefit. In most contemporary business environments, the will be forced to rely on tangible benefits for the approval of projects (and to demonstrate a return on investment). As a result, the project should spend a reasonable amount of effort on detailing the benefits in easily measurable terms.

Business benefits can be catalogued and defined in 6 key areas:

  1. Commercial viability: Depending on the entity, viability is a measure of profitability (e.g. private company) or alternatively, is a value-for-money measure of service delivery proficiency (e.g. public education).
  2. Productivity: A measure of efficiency where the degree of output is measured against a unit of input, quality standard or other prescribed criteria. Productivity measures can equally be applied to the production of goods (tangible) and services (intangible).
  3. Employee Engagement: The extent to which an individual is connected to their work. This is significant as engaged staff put in over and above what they are paid for (their ‘discretionary effort’) to create results.
  4. Customer satisfaction: The extent to which a customer is happy with a product or service. It can be a quantitative or qualitative measure of an organisation's ability to attract and capture a market segment and then build an enduring customer relationship.
  5. Governance and compliance: The organisation’s ability to assure conformity and adherence to both internal (e.g. policy) and external standards (e.g. legislation).
  6. Social and environmental impact: The organisation's ability to achieve business objectives whilst managing the enduring impact on people and the environment.
Business Case

A document capturing the reason for initiating a project or idea with particular emphasis on the business benefits. This document is generally used to show the value of the project to others and capture compelling arguments as to why a project should go ahead. This business case can be supplemented with a future-dated media release to help portray the vision in stakeholder-centric terms.

Business Owner

The individual (usually referred to by virtue of their role or position) that is the primary custodian to assure achievement of the business benefits to be achieved through the design / enhancement of a product, artefact, team, system or process.

Business Representative

The individual (usually referred to by virtue of their role or position) that is the primary beneficiary of the business benefits that are achieved through the design / enhancement of a product, artefact, team, system or process. This person is the link between the project and the business strategy/goals and is usually a channel to represent the Voice of the customer.

Typically, the Business Representative is a key member of the core team.

Business Value

The highest priority Agile principle is to, "satisfy the customer through early and continuous delivery." This principle affects a range of Agile activities to ensure delivery of business value is the core reason for completing any task during an Agile project. Business value is often determined by understanding the business benefit that will be achieved through completing the project.

Business value arises in a range of interactions and agile artefacts including:

  • Story elaboration: Story cards must display discrete business value during an elaboration session, otherwise they are probably just a card to track an individual’s activity.
  • Backlog grooming: Where the business or product owner ensures the business value of story cards is evident and clearly used to prioritise the backlog.
  • Minimal marketable feature: A set of features that are grouped to ensure that when they are released, they will deliver a significant contribution to the project’s overall business benefit.
  • Iteration: A time boxed period of work that aims to deliver something that the business or product owner would describe as having business value.

Refers to the pace a core team can continue to sustain for the duration of a project. Finding a sustainable pace is generally determined after a few iterations are completed and the velocity is tracked and performance via a retrospective process.

Change Manager (CM)

A key project role usually structured into the core team. The CM is primarily responsible for managing the ‘people-related’ aspect of a project, particularly if the project is delivering changes that will impact people. NOTE: In Agile, the practice of Change Management is distinctly different from the IT definition of a change management, which refers to the process of tracking variation.

The CM works with the Project Manager, Iteration Manager and Communications Manager to identify business impact, calibrate the appetite for change, manage stakeholder engagement and address resistance. Unfortunately, the value of a CM is typically under-appreciated in business projects.


See Project Charter.


Is a strategy that involves organising information into logical groupings so that it is easier to manage and communicate. Chunking is also a strategy to improve memory retention. Chunking can be used in presentations to make it easy for an audience to understand and remember your messages. Chunking is based on the understanding that an individual's memory is easily overloaded by excessive detail or lack of structured information.

Agile uses chunking to group stories into features, features into minimal marketable features (MMFs) and MMFs into releases.

Communication Manager

A key role in the core team. Responsible for facilitating the design and delivery of communications. The Communications Manager works closely with the Change Manager to engage stakeholders, understand their needs and manage their expectations using a variety of media.

Core Team

The people responsible for carrying out the day-to-day work – either as a project team or work group. The core team are typically the 'doers'. Through applying the Agile principles and practices, the core team is responsible for elaborating the scope of the project and making decisions about how the work will get done.

The team is usually made up of a cross-functional group of people with the skills necessary to deliver the planned outcomes. The core team typically consists of the following roles:

The core team can also include:

Course Correct

Using the feedback gained from showcases, retrospectives, steering committee meetings and other communication channels to re-orient activity towards achieving business requirements. The aim is to ensure the day-to-day work remains relevant and cost-effective in achieving the desired outcomes that will deliver the business benefits.

Cross Functional Team

A team comprised of members drawn from different functional areas across the organisation. A cross-functional team can also refer to a group of people with the range of skills relevant to completing the work. A cross-functional team is better equipped to generate wisdom of the crowd than a team of overly similar roles.


The primary beneficiary of the core team's output. Customers may be internal (e.g. CEO) or external (e.g. product consumer). Ideally, the customer is directly involved in informing the work of a core team. If the customer is external, then getting them involved in the core team is not always practical, so the customer’s interests can be represented by the Product Owner, Business Owner and / or Sponsor, or by incorporating the Voice of the Customer using tools such as personas to represent their interests within the project.

Definition of Done (DoD)

The criteria or series of steps that are used to determine when an artefact or work packet is complete. Defining the criteria to determine the DoD should involve the and occurs during iteration zero. Teams often use the 3 Done’s (Done, Done and Done), technique to confirm when a work packet is complete:

  1. Done 1: Have the acceptance tests on the been met?
  2. Done 2: Have the project’s broader end-to-end tests been passed?
  3. Done 3: Has the Product Owner passed the as complete and ready to deploy?

Team's should adapt the DoD to their specific requirements, however having cards as partially done, and then completing a big deployment each release is not an efficient or Agile approach. When a task is done, it should be ready to deliver to customers (even though the product owner may choose to bundle tasks and features into a release). This delivery should include all required change management, business readiness and approval artefacts.

Definition of Ready (DoR)

The criteria or series of steps that are completed to prepare a or ready for commencement. Defining the criteria to determine the DoR should involve the core team as much as possible. The focussing question used to define the DoR is:

"Does a person who will be completing this task have the necessary and sufficient information required to commence work, achieve all of the objectives of the task, and perform all steps as agreed in the team's definition of done?"

Typically a definition of ready includes elaborating a with sufficient detail, assigning a priority using MoSCoW, defining acceptance/success criteria, designing a prototype or mock-up of the expected outcome, and obtaining SME or Product Owner confirmation of the requirements.


A tangible artefact that is produced by the core team to satisfy the requirements of a customer and ultimately contribute to achieving business benefits. A deliverable could be a report, a document, a product, a service, server upgrade, a website, etc.

Design Phase

The Design phase comes after the Idea and Discovery work been completed and prior to Implementation.

This phase is designed to create a compelling case for change and unite stakeholders behind the project's goals and objectives. A dedicated core team consisting of representatives from all teams that would be involved in the Implementation should be formed to complete the following more detailed work:

  • Identify all business features.
  • Break down features into smaller work tasks, user stories are useful for this step.
  • Build a prioritised backlog based on business value
  • Agree on a solution design including completing any procurement activities
  • Figure out who you need, in what roles to complete the work
  • As a team estimate how long each work task will take
  • Structure the project into phases that can be released independently (i.e. where each release has business value, aka minimal marketable value.
  • Agile uses a "release early and release often" approach to deployments. The more releases completed and mastered, the less risk involved in performing future releases. Big bang releases place unnecessary pressure on teams to get it right with only one shot.
  • Define and capture project risks, assumptions, issues, dependencies and constraints.
Consider a go/no go decision at a detailed level. That is, determine if the costs stack up for return on investment? A good technique to describe a project in terms of business benefits, delivered scope, and ideal timeframes, is the future dated media release. If stakeholders/approval authorities remain convinced, proceed to Implementation.

Discover Phase

Discovery phase activities occur after the Idea work has completed. They seek to understand the problem or opportunity in more detail. Often lean or other assessment methods are used during this phase to quantify the issues and the planned response.

Discovery activities ensure the business understand the benefits and risks of proceeding and moving away from the status quo. This phase also serves as a checkpoint to confirm if the Project Sponsor’s peers and stakeholders are willing to invest.

A dedicated team should be formed for a period of time sufficient to:

  • Better understand the opportunity or problem
  • Confirm measurable business goals and objectives for the project that are linked to established organisational strategies (consider using SMART goals)
  • Start to involve delivery staff and partners in this phase to consider and assess various high-level solution options, for example, build, buy or a combination of both.

At this preliminary level, decide if the costs stack up for a return on investment? If so, proceed to the Design Phase.

Distributed Teams

A distributed team that has individuals working on the same project but not physically located together. The preferred mode of working with an Agile approach is face-to-face. Projects are encouraged to co-locate their cross-functional teams to minimise the negative affects of distance. Thomas Allen discovered this affect in the 70s (known as the Allen curve) where communications significantly reduced once people were separated by more than 50 metres.

To counter this challenge, teams that cannot be co-located for cost or operational reasons should employ every technique or technology at their disposal to simulate proximity. Always-on Skype ™ TVs are a good low-cost option to create the sense of sharing office space. Live chat or webcam systems are also useful to encourage rich conversations among team members.

Distributed teams operating in different time zones should maximise the overlapping periods of their working days. This usually involves teams starting earlier or finishing later – even an extra hour per day is incredibly useful to maintain the shared contribution to the project's goals.


The process of defining / refining a story or further exploring a matter to foster a better understanding of it. Elaboration requires engaging with the or other stakeholders to harvest information to expand existing / simple information to create a richer, more complete 'whole'. For example, the process of defining a user story requires elaboration by the customer. In this case, the core team expands their thinking through the customer specifying details around their desired outcomes and business benefits.

Elaboration is also be used to provide nuance and detail to complex stories or further explore large features by chunking epics into more doable work packets or tasks.


A collection of Stories that makes up a larger narrative. Epics are usually chunked down into smaller stories so that they can be managed as series of smaller, more doable tasks.


The process of determining the size, and subsequently, the effort and time required to complete tasks. There are three main contexts where estimation is applied:

  1. Size: Initially, work is sized via a high-level estimate using a relative unit (e.g. points rather than time). The two practices that can be used to determine the size of work are planning poker and T-shirting.
  2. Velocity: How much work the expects to 'burn through' in an iteration. Velocity is usually based on previous iterations and tracked using burn down or burn up charts
  3. Effort: An estimate of effort typically using an agreed unit of time (hours or days). The estimation of effort indicates how long it will take the team member(s) to complete the work (based on previous iterations) and can be used to manage resourcing requirements within a team.
Extended Team

People in the extended team play an important role but are not dedicated to the doing the work on a day-to-day basis. Extended team members have a vested interest to support the core team and ensure that the core team members are enabled to get on with the job.

The project manager is responsible for relationship management of the extended team. The extended team typically consists of the following roles:


A succinct description of the key attributes of a desired outcome, deliverable, artefact, product or service. Features are usually determined when the process identifies the desired outcomes and benefits associated with the identified problem / opportunity. The voice of customer outputs are assessed to identify the features of the desired products or services that will be produced to address the problem / opportunity.

Features are chunked through the process of elaboration with stakeholders to become a series of tasks that are tracked on the Agile wall. Features should also be solution/system independent as the represent a business or customer oriented features should also be solution/system independent as the represent a business or oriented requirement.

Feature Wall

See Agile Wall.

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.
Flight Plan
A term that can be used synonymously for release plan. Where a release plan is typically timeboxed in months, flight plans are usually focused on tactically defining the activity to occur in weeks or days. Flight plans can also be used to describe the work that happens with in an iteration.

As the name implies, building your way of working upon poor foundations will lead to a very 'fragile' implementation of 'agile'. Small hurdles will become insurmountable and trivial issues will become major impediments. Shane Hastie summarised these well in his Vancouver presentation (2012). If you start to see these issues, there is a very strong chance that your foundations and poor, and Tragile is imminent:

  • Unavailability of the sponsor or key stakeholders
  • Difficult to organise workshops due to agendas and time constraints
  • Estimates or plans imposed on the core team
  • Inability to agree within the team on estimates
  • Everything is prioritised as Critical!
  • Estimates treated as quotes
  • Lack of a competent facilitator
  • Overly dominant personalities in the group
  • Hidden agendas
  • Lack of empowerment for the core team
  • Being too polite to tackle real issues (the Tyranny of niceness)
  • Pressure to magically increase velocity resulting in unsustainable pace
  • Reverting to silo behaviour and blame games
Future-dated Media Release

This kind of media release is written during the Discovery and Design phases of a project, but written as if were published on the release or go-live date. The release is never published, however it serves to confirm the scope, benefits, timings and impacts of the project on its stakeholder community.

The Sponsor and Owner should take primary accountability to author this release and keep the content under 500 words. This ensures only the key benefits are highlighted and quantified in terms that stakeholders understand.

The format of a media release answers the question for stakeholders of, "what is in it for me". This is different from the typical format of Project Charters or Business Case documents that are written from a more project-centric perspective, and often require assumed knowledge of the strategic drivers, none of which are relevant to the end users or beneficiaries of the project.

Major organisations like Amazon and the Suncorp Group use this tool to keep the team focussed and ensure scope does not diverge excessively from the planned course without good strategic reasons. If it does, the media release should be re-written to reflect the course correction.

Go No-Go

A decision, checkpoint or gateway where an individual or group of stakeholders are required to make determination to proceed ('go') or not ('no-go'). Go / no-go decisions usually occur through a formal, preferably pre-defined, process based on a combination of criteria such as:

  • confirmation of completed scope,
  • product quality,
  • team readiness,
  • client readiness, and
  • operational support readiness.

No-go decisions may result in a deferral of progression to the next phase (assuming the outstanding criteria can be met in a suitable timeframe) or a cancellation of the next phase.

No-go decisions should not be seen as unsuccessful outcomes, rather using agile principles, the business owner may have received sufficient business value for this particular endeavour and choose to focus their efforts on alternative activities. This kind of business agility and subsequent cost avoidance speaks to some of the core benefits of an Agile approach.

Grandma Test

A test designed to determine the user-friendliness of communications. The test question is: "Is this written in such a way that my grandmother would understand it?"

Idea Brief (see also SOAP)

A document, generally no more than 1-2 pages providing information derived from the Idea phase of a project. It will usually contain the following:

  • What is the core idea (stated as simply, and compellingly, as possible)?
  • What problem are you trying to solve? What problem(s) are you NOT trying to solve?
  • Who are you solving it for?
  • How might you solve it / how could this work?
  • What $ investment would you be willing to make to solve it?
  • Why should the reader care? What is in it for them? What do you need from them?
  • How might this go wrong? And what will you do if that happens?
  • What and who do you need to complete a discovery phase?
Idea Phase

The first phase in an Agile approach starts with identifying the opportunity or problem. The Project Owner and Sponsor must establish a shared sense of purpose with agreement that actions are taken to capitalise on the opportunity or resolve the problem.

A small focused is assembled to:

  • Clearly articulate what the opportunity or problem is. Boundaries should be considered in order to ensure the scope is solvable and not infinite in size
  • Explore the benefits to be gained. In this phase the benefits are more often qualified rather than quantified
  • Understand the cost appetite of the business (also known as a cost wish)
  • Get endorsement from key stakeholders to progress into the Discovery phase

This last point is a key element of the Agile approach, as permission is not sought to commence the project, merely to progress to the next Discovery phase. This concept is taken from Lean "just-in-time" processes to ensure effort is sufficient and waste minimised.


See Implementation Phase.

Implementation Phase

The Implementation phase comes after the Design work has been completed. This phase is designed to deliver on the vision and solution defined during the Design phase. It involves ongoing collaboration with key stakeholders for the duration of the project and is designed primarily to maintain alignment between daily activity and delivery of the planned .

Implementation consumes the majority of time in an Agile project and relies on the dedicated core team to iteratively deliver the project as specified in the Design phase. Some key elements are:


Something that has happened (or is happening right now) that requires attention and management. An issue is different from a risk as it does NOT have a probability (because an issue is 'here and now') and is having an impact (usually adverse) on the project.

The response to an issue should be pre-defined as one of the controls proposed for the corresponding risk.

For more info see: Risks, Issues and Opportunities (RIO)


A fixed period of time during which activity is done to achieve a specific outcome. Iterations are usually 2 weeks in duration but can vary as required.

NOTE: I find that 1 week is not long enough to allow people to get on with the doing and 4 weeks too long as a team can start to drift off course.

Iteration Manager

A key role in the core team. In order for the core team to stay focused on maximising the amount of business value generated during the implementation phase, team members must assume the role of IM from time to time. Initially teams may have a dedicated person performing this role, however they should rapidly be assigning IM-related tasks to any member of the team within the first few iterations. Often an expert agile coach or facilitator can perform the IM role to help get the team moving in the right agile directions.

People performing IM tasks help to facilitate or coach colleagues through: iteration planning meetings (IPMs), backlog grooming, status reports, and tracking progress using burn down / burn up charts. Everyone in the team should be capable of performing these tasks to reduce the dependence on any one individual. This approach has the added benefit of adopting standardised approaches that the team can buy in to, as no one individual can dictate their personal style to the team.

Iteration Planning Meeting

A planning session undertaken collectively by the core team to determine what will be worked on in during the next iteration. Iteration planning occurs prior to commencement of the next planned iteration and requires a Backlog Grooming session to ensure all of the cards are already prioritised based on the higher-level release plan.

Commencing with the next highest priority, the Product Owner explains the card in more detail. The team probe and question, to determine relevant details necessary to elaborate the card. Elaborations may include mock up designs, process maps, acceptance criteria, testing approaches and necessary skills required to complete the card.

Given an elaborated card, the team may chose to merge or split the card to ensure the size of the card is suitable to complete within the planned iteration.

The team will then estimate how many cards can be drawn from the backlog into the upcoming iteration and commit to that delivery. Various artefacts are updated at this point to project the likely velocity of he team (burn up/down charts, release plans, project charters, status reports, and story walls).

Iteration Zero

This is the first iteration performed in the implementation phase and represents the setup for the team. No cards or tasks of business value or related to scope should commence in this first iteration. The goal is to ensure that when iteration 1 commences, the team can commence work unimpeded by any tools, facilities, resources or capabilities they need.

Most iteration zero efforts focus on the following activities:

  • Securing a suitable project space for collaborative working
  • Having the team co-located and 100% allocated
  • Obtaining collaboration technology to support (Skype™ TVs, Whiteboards, webcams)
  • Finding space for your agile wall and building the framework (taping it out usually)
  • Assigning Avatars to people
  • Developing a social contract
  • Obtaining all of the PCs, software and access needed to commence
  • Setting up document libraries or project collaboration portals
  • Adopting agile electronic tools if appropriate (JIRA, VersionOne, Trello etc)
  • Getting on technical tools in place (automated testing, continuous build, etc)
  • Erecting all BVC artefacts (risk walls, success sliders, etc)
  • Booking in all recurring meetings as per the team’s cadence
  • Supply of all stationery needed for the team (cards, blu-tak, pens, markers, etc)

Any other tasks as needed for the team to commence immediately.


Is a Japanese word that translates as "signboard" or "billboard". Kanban refers to the process of using visual triggers to help manage the work in progress on an Agile wall. Kanban is useful alternative to especially for service-oriented teams as it encourages work in progress (WIP) limits. This limit prevents and enforces the maximum amount of work that can occur at any one point in time. As work is completed, new tasks can be 'pulled' by the core team into WIP.


An event of significance that occurs at a pre-determined point in time. Milestones usually mark the end of a stage to signify the completion of a work package or phase. Milestones can be scheduled before the end of a phase so that if problems arise corrective action can be taken to ensure the outcome is achieved on time.


A diagram used to visually organise information. It is usually created around a single concept and drawn with an image in the centre of a blank landscape page, to which associated representations of ideas such as images, words and parts of words are added.

Minimum Marketable Feature (MMF)

The smallest set of functionality inherent in a product or service that must be realised in order for the customer to perceive value. An MMF is the Agile approach used to chunk features that the Product Manager can use for their release planning.


A prioritisation technique used to reach a common understanding on the importance of particular tasks, outcomes or features. The categories are as follows:

  • M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
  • S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways in order to meet go / no-go criteria.
  • C - COULD: Describes a requirement that is considered desirable but not necessary. This will be included if time and resources permit and often relates to cosmetic improvements or functionality for smaller user groups within the larger user population.
  • W - WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a given release plan, but may be considered for the future. Teams need to be clear if they are removing the need for this requirement permanently or simply deferring the work for another project or BaU team to complete (perhaps related to a pre-requisite activity from another project).

The upside of risk. In particular, opportunity recognition is an entrepreneurial skill that identifies the potential to achieving something greater then what was originally conceived.

In most organisations a significant amount of energy is spent on risk (hazard) and issue management and little on opportunity exploitation. Managing risks and issues bring comfort to Sponsors and executive teams because it increases the predictability of a project delivering what it was originally intended to do (even it comes at more cost). However, exploiting opportunities can provide a far greater return on investment.

Large organisations struggle with opportunity recognition as risk and issue management are far more 'real'. Whereas small business (that is, the 'small business mindset') is inherently more flexible and better suited to exploit opportunities out of competitive necessity. The Agile Principles are biased towards opportunity management.

A useful tool to help visualise opportunities is the Dynamic SWOT also known as a TOWS Matrix, where the original SWOT is expanded into an action-oriented approach: http://bit.ly/Y6tG1j.

For more info see: Risks, Issues and Opportunities (RIO)


Personas are used as proxy to represent an individual / group who is not present to participate in a process. For example, if a Voice of the Customer process is being used to elaborate the requirements for a project and the actual customer is not available, then an individual can assume the 'persona' of that customer for the purposes of the project.

Asking people to assume a persona is also a powerful way to build empathy for that particular person / role being 'channelled'.

Planning Poker

Planning poker is a consensus-based technique for estimating the relative size of tasks. It works by each estimator being given a deck of cards. Depending on the scoring system chosen, the deck of cards may read: '0', '1', '2', '3', '5', '8', '13', '20', '40', and '100' in large print. Participants are asked to rate each task with the cards but do not show the others their rating until everyone reveals their cards at once. Where there is disparity between the estimates, discussion can take place to finalise an effort/resource score for the task.

The numbering sequence may be exponential (e.g. 1, 2, 4, 8, 16, 32...) or Fibonacci (e.g. 1, 2, 3, 5, 8, 13, 21, 34...).


See Agile Practices.


See Agile Principles.


The process of determining what to do based on various inputs such as business value, risk size, etc. The primary technique for prioritisation is MoSCoW.

Process Owner

The individual (usually referred to by virtue of their role or position) that is primarily accountable for the design, governance and (usually but not always) execution of a business process. This includes maintaining and assuring the quality of the process inputs and outputs.

A Process Owner is usually not a member of the core team unless the nature of the project is significantly changing the processes as part of the implementation. If the team requires confirmation of specific process details or permission to change a process as part of their planned scope, the Process Owner should always be engaged. The team should identify this dependency and request involvement as an action from the iteration planning meeting (IPM).


Refers to the artefact's produced by the core team that offer tangible and / or intangible value to the customer.

Product Owner

The person who represents the key stakeholders and acts as the Voice of the Customer. He or she is accountable for ensuring that the core team delivers value to the business. The Product Owner writes (or has the team write) to represent their desired outcomes. The product owner works with the core team to create tasks which are then prioritised, estimated and added into the backlog.

The Product Owner and work together (sometimes they can be the same person) to ensure the following:

  • Establishing, nurturing, and communicating the vision for what they want in the product
  • Guiding the core and extended team on how to best provide value to the customer
  • Provide steering to the core team in its activity towards delivering the product

Provide steering about when to release the product.

Product Vision

A brief statement of the desired future state or artefacts that are to be achieved through a successful completion of a project. A product vision may be expressed in any number of ways including financial performance, creative genius, customer satisfaction, market share, functional capability or features of an artefact. The is an effective tool to communicate the vision in customer oriented language.


A project is a temporary endeavour undertaken by an individual or group to create a unique product, service or result with the ultimate purpose of delivering a desired benefit.

Projects have a clearly defined start and end. In corporate organisations, projects are best managed with the application of a structured approach and often require their own dedicated governance framework that is distinct from business-as-usual (BAU) governance.

Projects typically have an allocated set of resources (people and / or money) that are aimed to deliver a specific benefit. Projects typically do not have recurring budget implications.

A program is a group of related projects managed together to obtain benefits that would likely not occur if the projects were managed individually. While project management focuses on delivering the specific outcomes – program management is focused on achieving the strategic objectives and benefits of the integrated program.

A portfolio is a collection of projects or programs grouped together to facilitate the effective management of efforts to achieve strategic business objectives. A portfolio of projects need not necessarily be interdependent or directly related.

Portfolio governance is the centralised management of multiple projects, programs and possibly portfolios. This typically includes identifying, prioritising, authorising and monitoring projects and programs to achieve specific business objectives.

Project Charter / Project Plan

A Project Charter is an electronic document detailing the vision, mission and success criteria of a project. It is one of the most important documents in a project and should consider the impact of the project on all stakeholders. It differs from a business case in that the business case is used to justify or get approval for the project, while the Charter sets out the broader approach to deliver the project and holds all key information related to specific goals, governance structures, timelines, budgets, risks, roles and responsibilities, change management, communications, and solution options considered. It should serve as a single repository for all planning aspects of the project.

As a controlling document that lives throughout al phases of a project, appropriate document management controls (versioning, access, etc.) should be implemented to govern its use.

A presentation tool such as PowerPoint is useful to keep the word count low and leverage photographs, diagrams, etc. to convey key points. Most Project Charters in this format will be between 10 and 40 slides long depending on the size and complexity of the project.

Project Manager (PM)

A key role in the core team. An Agile PM is primarily responsible for managing outwards from the core team. They also help remove impediments that the team cannot resolve.

The project manager is primarily responsible for managing up to the sponsor and assuring the project lifecycle is tracking as it should. The PM acts as an interface between the Core Team and Extended Team to deliver a project.

Project Plan

See Project Charter.

Project Sponsor

The most senior member of the extended team and is responsible for setting the strategic vision for a project. The Sponsor needs to champion the project’s benefits and impact throughout the organisation, especially to colleagues and peers who will need to contribute staff, time, resources or effort to deliver the project.

A sponsor must commit to delivering based on the project’s deliverables. The Agile approach of releasing business value often and early requires specific consideration from a sponsor of an Agile project. Traditionally, Sponsor’s would be asked to commit to benefits for an entire financial year. Agile projects should encourage business planning staff (Finance, HR, etc.) to consider a chunking approach for both benefits and funding. Specially, so long as the project keeps delivering releases with minimal marketable features that are adding business value, then funding should continue. Once the Sponsor, or perhaps the Steering Committee, believe the return on investment is not delivering a positive benefit, then funding can cease. This incremental funding approach to portfolio management is an effective way for an organisations to realise the value of an Agile way of working by also focussing on what not to do.

A critical role that a Sponsor must play is that of "Chief Impediment Remover". If the team raises blockers during a stand-up, at a retrospective, or during a showcase, then a Sponsor needs to play the role of a servant leader and clear a pathway for the team, in order to maintain their velocity. In most cases however, the team will exhaust multiple efforts to resolve issues themselves and the Sponsor is not called in to action.

Project Team

See Core Team and Extended Team.

Project Wall

See Agile Wall.

See Technical Debt.
Relative Estimates
See Estimation.
Release Plan

A schedule for delivering features, functions or services into productive use. Typical release plans include the key features to be delivered, along with corresponding release dates. Release plans also expose key milestones or dependencies on parallel project activities.

Release Planning

Refers to planning activities used to estimate when features, functionality or services will be released into productive use. Activities include projecting the level of effort in terms of the number of iterations that will be necessary to deliver the desired features. A release plan represents how much scope that team intends to deliver by a given deadline.

The scope of releases is usually referred to in groupings of minimal marketable features (MMFs). Each MMF must also meet the definition of done to ensure it can be deployed into the operating environment.

A meeting held at the end of each iteration and following all releases, in which the team reviews its actions by answering the following questions:

  1. What is working well for us (that we should keep doing)?
  2. What could be improved or done differently?
  3. What is puzzling us?

The discussion is recorded and actions are assigned to individuals with corresponding due dates. Actions from retrospectives should be discussed at stand-up meetings like any other significant activity performed by a team member.

RIO – Risks, Issues & Opportunities
AA dedicated space on a wall visualising details of the risks, issues and opportunities associated with the project or business unit. The RIO is best managed as a BVC and should be regularly discussed in stand-up meetings and actioned accordingly. A simple matrix is often used to plot the relative impact and relative likelihood of different RIO’s occurring.

The chance of something happening that will have an impact on a project / business. The potential for the consequence of risk events can be either positive (desired) or negative (undesired). ISO 31000 defines risk as: " ...effect of uncertainty on objectives"

Risks are different to as there is still an element of probability associated with a risk whereas an issue is here and now and requires management.

The primary way of dealing with risk includes:

  1. Avoiding the risk by not starting or discontinuing activity that gives rise to the risk
  2. Accepting that risk in order to solve a problem or pursue an opportunity
  3. Do something to remove the source of the risk (e.g. remove the hazard / trigger)
  4. Do something to change the probability of the risk manifesting
  5. Do something to change / better manage the consequences
  6. Share the risk with another party (e.g. through contracts or risk financing)
  7. Accept the risk and get on with it anyway

Risk ratings should recognise the current residual ratings (both likelihood and impact) after controls or mitigations are in place, as well as the future ratings once any outstanding actions are completed. For more info see: Risks, Issues and Opportunities (RIO)

Role Play

The use of focus or reference groups to role play using the project’s deliverables can be key to assessing their likely success in a production environment. However focus groups can be overly time consuming for participants and logistically difficult to coordinate for project teams. Even worse, is when the people selected are not representative of the wide range of customer or users in scope, leading to incorrect or invalid assessments of the project.

Personas can play a useful role as an alternative to focus or reference groups, as they are virtual representations of your typical customers. Using various tools to obtain the Voice of the Customer (VoC), Personas can them form part of the team’s approach to designing and testing features through role playing. For example, "what would Mechanical Mike want out of this", or "do you really think Clever Claudia would put up with that"? This fast tracks the feedback process and ensures a broad range of requirements are considered in a time and cost-effective manner.

Root Cause Analysis

A method of problem solving that looks deeper into the symptoms of an issue to find out what is causing them. Several established yet simple techniques can be used to complete these tasks, staring from verbal or facilitated sessions and moving to more statistical searches for root causes:

Be careful with correlations as data can often yield a correlation where there is no cause and effect. For example, there is a strong correlation between the time of day when a rooster crows and when the sun comes up, but ...he doesn’t cause it.


The scope of a project is represented in multiple levels, with each level progressively revealing more detail. The following list breaks down project scope from its highest element into its lowest level of detail. The linkage between each level is shown firstly in the project charter and once the implementation phase commences, on the teams agile wall:

  • Vision (Project Charter)
  • Objectives (Project Charter)
  • Goals (Project Charter)
  • Benefits (Project Charter)
  • Features / Minimal Marketable Features (Release plan)
  • Epics
  • Stories / Task Cards (Agile Wall – backlog)
  • Tasks (Agile Wall – backlog)

Scrum is a simple framework for effective team collaboration on complex projects. It is the same as a stand-up meeting where team members share relevant information on what they are working on and if they need some assistance in removing blockages.

In larger programs of work where multiple projects are contributing to a common goal, representatives from each team (the person acting as Iteration Manager) will attend a Scrum-of-Scrums meeting to share project updates with other Iteration Managers and Program staff.

Scrum can also refer to the formal agile methodology that is one of the predominant agile approaches used globally. Many agile practitioners have completed Scrum certification and will use the terms Scrum and Agile interchangeably.

Self Organising Teams

As a team matures it will begin to organise itself rather than passively waiting to be directed by an external force such as a Project Sponsor. More importantly, this means that the team does not solely rely on the Project Manager or any type of perceived leader to lead the team. Using the principle of wisdom of the crowd, operational decisions are distributed around the team initially to those who have the most detailed knowledge (e.g. Subject Matter `) with the team then making an informed decision as a group. This process is not to be mistaken for groupthink.

NOTE: On 'smaller' projects (e.g. low risk, low cost, low benefit) a mature core team is often able to handle the decision making associated with executing a project. On larger projects, self-organising is more challenging and an extended team or steering committee (SteerCo) is often required to ensure that the deliverables and milestones are achieved to assure business benefit is realised.


An event held by the core team to demonstrate completed artefacts / products / features to key stakeholders. The aim is to demonstrate progress towards meeting stated business goals and objectives. Stakeholders will also have the opportunity to provide feedback and propose before activating the release plan. The goal of testing however is to minimise the likelihood of that occurring in a showcase as the business defined acceptance criteria are used to meet the for each card.

If showcases are identifying flawed deliverables or they are triggering course corrections, the project may have other concerning issues at play, such as a Product Owner that is not empowered or skilled enough to perform the role, or perhaps a stakeholder group that has not bought in to the project's vision. These symptoms would warrant some urgent root cause analysis from the Project Manager to understand the source of discontent.


See Estimation.


This term refers to the instinctive detection of something that "smells a bit off". This kind of subjective assessment of issues and risks draws on the principles of collaboration, transparency and simplicity. As members of the are encouraged to be involved in all manner of interactions throughout the life of an Agile project, it is during these interactions that they may see, hear or observe something that intuitively does not feel right. Once they have ‘smelt’ a possible symptom, stakeholders are encouraged to raise it at a retrospective meeting or if urgent, with a member of the core team. The team's social contract should embrace this kind of feedback and seek to put in place actions to remediate the identified issue or investigate the symptoms to identify the root cause(s).

Social Contract

An artefact that represents the agreed values and behaviours that all team members will abide by. The social contract is set by the team at the commencement of the implementation phase and closely aligns with Tuckman’s principles of accelerating the forming, norming and storming phases of group development.

The core team gets together and discusses the way the team wants to operate together. They create an agreed set of rules that:

  • Is created when the team first forms
  • States everyone’s understanding of how the team will behave and interact
  • Is a living document
  • Should feel comfortable for anyone on the team to enforce it

Teams need social contracts because:

  • Teams need to own their practices and standards and work in a way that is comfortable to them, especially needed to obtain the benefits from a Self-Organising Team
  • People invariably forget their agreements over time unless they are written down
  • People come and go over time; new members need to know ‘how we work around here’

It helps build the character of the team and create a shared sense of identity.


A spike is a short and sharp piece of activity designed to remove uncertainty. The need for a spike should be decided as stories or tasks are elaborated during the iteration planning meeting. This is where the core team will decide that the definition of ready cannot be completed for a given task, as more research is needed to either qualify/quantify the problem, or consider the viability of possible solution options.

  • It will usually be completed for the purpose of researching, validating or testing an idea. Spikes occur within an and are managed using standard agile and applied to any other task card (e.g. dedicated owner, estimable, DoR, DoD, etc.). Spikes are not about working hard to finish a task or complete a – that is just hard work.
Sponsor / Sponsorship

The sponsor is the individual (usually a manager or executive) with accountability for the project's ultimate success or failure. The Sponsor is primarily concerned with ensuring that the project delivers the agreed business benefits within the organisation’s investment appetite. The Sponsor acts as the representative of the organisation, and plays a vital leadership role through:

  • Providing the clarity of how the project contributes to specific organisational strategies
  • 'Championing' the project, selling and marketing the project throughout the organisation
  • Providing business expertise, executive coaching and guidance to the Project Manager
  • Acting as the link between the project, the business community and perhaps most importantly, various management decision making groups
  • Acting as an arbiter and making decisions beyond the authority of the Project Manager

Performing the role of chair on the project’s Steering Committee.


The Scrum term for an Iteration. The sprint starts with a sprint (iteration) planning meeting. At the end of the sprint (iteration) there is a sprint review (iteration) retrospective meeting.


Anyone external to the team with a vested interest in the outcome of the team's work. The Project Manager, Change Manager and Communications Manager must take primary responsibility for managing, tracking and coordinating interactions with stakeholders.


An informal daily team meeting held to provide an update to colleagues in the core team. The stand-up allows participants to know about potential challenges as well as coordinate efforts to help each other resolve risk or issues. The meetings are usually time boxed to 30 seconds per participant, and are held standing up to remind people to keep the meeting short and to the point.

Ineffective stand-ups often result in each person pointing to their card on the agile wall and providing a verbal status update that is mostly irrelevant to the other team members. A 'camp fire' is a useful metaphor to consider when comparing stand-ups to other meeting types (i.e. talk to each other with purpose, not aimlessly at a wall).

Status Report

The team should produce a status report at the end of every iteration with the format, level of detail and content negotiated with the Project Sponsor. The status report should summarise the following key elements:

  • Deliverables - work completed during the current iteration versus the planned scope.
  • Plan - approved work planned for the next iteration, shown within the release plan
  • Velocity - Updated burn up/down charts (for the iteration and the overall project)
  • Schedule - initial estimated dates, authorised changes and any updated estimates
  • Budget - original approved budget, authorised changes and current estimated forecast
  • Issues - any issues or risks triggered that have resulted in approved changes to scope, schedule, budget or quality.
Steering Committee (SteerCo)

A Steering Committee (SteerCo) is usually chaired by the Project Sponsor or their direct leader. In some organisations a CFO or CEO chairs all Steering Committees. A group of senior staff at an equal or approximate organisational level to the Chair would be formed to govern the project. An example of the kind of representatives required includes: risk, finance, technology, human resources, program/portfolio management, legal/governance, media/public relations, etc.

The Project Manager would work with their Owner and Sponsor to schedule meetings and present in line with the projects cadence. A project with fortnightly iterations would adopt SteerCo meetings every 4 weeks to ensure consistent status reports can be generated. All issues that would alter the Project Charter should be tabled, discussed and agreed to by the SteerCo members before proceeding (new features, different timelines, changing budget, etc.).

The SteerCo should also be invited to showcases to understand the progress being made each iteration. This invite should extend to ad hoc "walk the wall" sessions where they can come in to the project room, unannounced and pursue the agile wall to get a sense of what is going on at the coalface of a project. By embracing transparency, our experience shows that senior members of staff relish in the opportunity to remove blockers, clarify puzzles or have their own expectations managed with regard to velocity (shown in burn down charts).

Story (Cards)

An Agile artefact where a user story is written onto a small library index card or post-it note representing a 'promise for a conversation' to be held at a later date.

See task card and Story for more detail.

Story (User Story)

A user story is different from other requirements documentation techniques (not to be confused with Use Cases) as it places the user, an SME or Product Owner usually, at the forefront of specifying what business activity they want to be able to do. Stories take the format of:

As a ...customer, I want an ...outcome, so that I can ...benefit.

  • A customer needs to be a beneficiary of the project, not someone within the team
  • The outcome must be an achievable goal that can tested and passed as complete
  • The benefit is not mandatory, but it does help the team with context to understand why we would bother with delivering this requirement

Additionally, stories uses a 3 phase process (based on Ron Jeffries thinking, one of the original signatories to the Agile Manifesto) to progressively add more detail to the requirement. Each phase represents a distinct activity within a project’s cadence:

  1. A Story Card (an index card or Post-it note) is a physical token giving tangible and durable form to what would otherwise only be an abstract idea. This token represents a ‘promise for a conversation’ to be held at a later date.
  2. The 'promised' conversation takes part during the Iteration Planning meeting where the team discuss the card to reach a common understanding. This discussion is mostly verbal, but could be supplemented with whiteboard diagrams to aid in understanding.
  3. The confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally. A confirmed, elaborated story should be documented with all necessary information for a team member to complete the card in the next iteration. Agile flexibility dictates that you should not elaborate too far in advance (no more than 2 iterations usually), as the act of completing some stories, could influence future stories and introduce rework.
Story Board

See Agile Wall.

Strategy On A Page (SoaP)

A document (ideally a single page) to succinctly communicate with stakeholders. The core elements are:

  • What is the situation / context?
  • What are the issues / risks / problems / opportunities?
  • What are the options to respond to the issues / risks / problems / opportunities?
  • What is the recommended approach?

A SOAP is typically used during the idea phase to engage with stakeholders.

Subject Matter Expert

A key role in the core team. A person with authoritative functional knowledge in a particular area or regarding a particular topic. SMEs are often assigned to the on a full-time basis, however some SMEs are brought in to the project to help with requirements for a specific component. The Product Owner should assist with identifying suitable SMEs to contribute to the project's requirements.

Success Sliders

Sliders represent the Steering Committee's position with regard to making various trade-offs within the day-to-day life of a project. There are usually 4-5 different sliders with a scale from Fixed to Variable for each. The notches on the scale need to equal the number of sliders so that no one slider can be in the same position (producing a forced ranking of the sliders). A common example would include: Quality, Time, Cost and Scope.

A project team can use these sliders and ensure they are part of the project’s BVC. This way a project team member can ask themselves which trade-off they should make when they reach such a decision point, e.g. take longer, go quicker, highest quality, cheaper, etc.

Typically, the Discovery and Design phases would confirm the project's sliders with the Steering Committee.

Sufficient (Necessary and Sufficient)

Doing only what is required to meet the needs of the customer or satisfy the definition of done for a task. Sometimes, 'sufficiency' demands a higher level of quality and effort, however most non-agile artefacts are over-engineered beyond what is immediately required.

This sufficiency principle is aligned to the concept of minimum marketable features. The MMF principle refers to the minimum amount of features required in order to take a product (often working software) to the ‘market’ of internal and / or external customers.

System Owner

The individual (usually referred to by virtue of their role or position) that is primarily accountable for the procurement, installation and maintenance of enabling tools (e.g. software) to optimise business process execution and underpin the achievement of business benefits.


A process where tasks are compared to one another and categorised as either small, medium large, extra-large or XX-large. The t-shirt size is analogous to an exponentially growing number such as Extra small = 1; Small = 2; Medium = 4, Large = 8 and so on. The process for conducting T-shirt estimation uses the processes outlined planning poker.


A task is an activity performed, usually, by a member of the core team. Tasks can be represented on physical index cards and displayed on an agile wall to ensure all members of the team are aware of who is performing the task, what its priority is, roughly how long it may take and briefly, what activities the task will include.

A task will move between various statuses as it progresses from 'not yet started', to 'in-progress' and finally 'done'. Some teams choose to define a more comprehensive workflow for tasks depending on their specific requirements.

For more info see Task Card.

Task Card

A critical agile artefact that captures key attributes onto a small library card or stick note.

Refers to a requirement, feature and/or chunk of business value that can be prioritised, size-estimated and is compliant with the set definition of done. Task cards are generally hand written cards placed on the wall and referred to and moved in stand-up meetings. The basic unit of communication, planning, and negotiation between the agile team, business owners, and the product owner.

These cards typically include of the following elements:

  1. Title: a succinct description of the work (that passes the Grandma test)
  2. Description: a brief breakdown of the work, often in the Story format
  3. Estimate: a relative size of the work indicating complexity of the requirement, generally expressed in story points (such as 1, 2, 3, 5)
  4. Acceptance criteria: descriptions of how the story will be assessed for completeness
  5. Assignee: who can explain and account for the work (use an Avatar for a bit of fun!)
  6. Priority: using MoSCoW or even just high (H), medium (M) or low (L)
  7. Unique ID: a unique number assigned to each card, sometimes system generated

Sometimes referred to as a story card.

Task wall / Task-board

See Agile Wall.


See core team and extended team.

Technical Debt/Refactoring

Most projects build their deliverables using existing assets, capabilities or systems. Even those projects that start with a blank canvas will start to build things that given time, should be updated, re-authored or improved. This issue is referred to as technical debt.

As new versions of software or new standards are released into the broader environment, what the project has delivered or inherited has a risk of becoming obsolete. Rather than defer these updates to the next project, Agile believes that "refactoring" as you go is the more efficient way to keep your deliverables up-to-date and easier to support for the next team or project. As a part of elaborating a the technical members of the team should consider any technical debt they are likely to encounter and propose inclusion in the acceptance criteria of sufficient refactoring.


Testing in Agile projects represents a critical function to maintain the quality of deliverables. Importantly, everyone in the core team is responsible for product quality. An Agile saying from software development is: "testing is far to important to be left to the testers". This is not a slight on professional testers, their role is important in Agile projects, it is more that testing should not be left to testers alone.

At the heart of Agile testing is the determination of business value, where the customer’s most desired outcomes are delivered as fast and as frequently as possible. To maintain cadence, teams use a range of techniques to capture examples of the desired behaviour of the project’s deliverables and use these for testing confirmation. Importantly these techniques work best when they make use of the cross-functional nature of a strong core team:

  • Specification by Example – where requirements are captured and illustrated using realistic examples instead of abstract statements. This approach is particularly successful for managing large-scale projects with significant organisational complexity. By ensuring each example is the source of truth for stakeholders, analysts, testers, developers, etc, work towards delivering business value can remain aligned to the envisioned example. A major advantage of this approach is that the example can live on beyond the project as the system’s documentation. This can then be use for any future change requests, audits or support requirements.
  • Agile Testing Quadrants (based on Brian Marick‘s original testing matrix) can guide a team into performing one of four different types of testing based on their given situation. Lisa Crispin has summarised the options the best in this diagram.
  • See Grandma test for a simply way to ensure the language used in story cards or tasks is easily interpreted by all stakeholders
  • See Personas for a way to perform usability and sociability testing among a range of different user types. This is a faster option that performing extensive focus group testing when the Product Owner may be unsure of the business value of particular features.
The three c's

Ron Jeffries, one of the original signatories to the Agile Manifesto, suggested 3 distinct phases to developing a user story: Card, Conversation, and Confirmation.

  1. A story card (an index card or Post-it note) is a physical token giving tangible and durable form to what would otherwise be an abstract idea. This token represents a "promise for a conversation" to be held at a later date.
  2. The 'promised' conversation takes part during the Iteration Planning meeting where the team discuss the card to reach a common understanding. This discussion is mostly verbal, but could be supplemented with whiteboard diagrams to aid in understanding.
  3. The confirmation, the more formal the better, ensures that the objectives discussed during conversation have been established. A confirmed, elaborated story should be documented with all necessary information for a team member to complete the card in the next iteration. Agile flexibility dictates that you should not elaborate too far in advance (no more than 2 iterations usually), as the act of completing some stories, could influence future stories and introduce rework.

A time period of fixed length used to encourage a finite amount of work for repeatable activities. When applied to an Agile way of working, iterations are 'time boxed' to ensure consistent planning approaches, and meetings are always time boxed to ensure administrative activities are kept to a minimum stand-ups, Retrospectives, Iteration Planning, etc.

Time boxing is one specialised form of cadence. It’s like a metronome, giving a single tick, just like the beat of a drum. Once a team become used to time boxing they usually incorporate for most activities into their social contract.


This label is applied to 'tragically implemented agile', as well as 'Agile projects ending in Tragedy'. We know that poorly run projects will fail, just as poorly implemented agile principles and techniques can just as easily fail as well. Some of the most commons causes emerge from adopting Fragile or WAgile, each of which have their own set of pitfalls. When projects fail, people look to blame tools or methodologies and often people can start to lose confidence in an Agile way of working. Proponents of Agile that promote 'fast and loose' attitudes such as, we don't need documentation, let’s start building right away, don't worry if business representatives can't make it, or don't worry about those bugs, we can fix them later, are all promoting a path towards 'Tragile'.

User Story
See "Story".

Is a measure of the volume of work a team has completed during an iteration. Velocity is measured by adding all of the points of the tasks completed during an iteration and tracking them on a burn down or burn up chart. If points are not being used then velocity can be measured using hours (or days) per task / deliverable.

Understanding the velocity of an iteration can be used during iteration planning sessions to inform how much work the core team should plan on completing for the upcoming iteration.

Velocity can also be used to make estimates around resourcing requirements. For example, if the core team has been sustainably completing 100 points worth of work / fortnight for several iterations, and requires 200 points worth of work to be done next iteration, then there is clearly going to be a problem. Basic maths would lead one to conclude that the core team needs double the resources to do double the work. But teams don’t work this way. Firstly, no team is 100% efficient so you would probably need 120% of the resources to do double the workload. Secondly, teams take a while to get up to a sustainable . So even if you got the extra resources, this does not assure that they will be as productive.

Voice of the Customer - (VOC)

A term used to describe the in-depth process of capturing a customer's expectations, preferences and aversions – their hopes and fears! Understanding the Voice of the Customer (VoC) is a market research technique that produces a detailed set of customer wants and needs and any other intelligence that can tell you more about the customer.

This information is critical for constructing user stories and defining the features, deliverables and milestones for a project.

War Room

A room (or dedicated location) that provides a space where people come together to manage work. The space serves as a centre that allows a team to operate in a predictable manner to exchange ideas, manage plans and share information in an active way.

As the term has military connotations, it may be preferable to label your space with a phrase that is more amenable to your workplace. Regardless of the label used, the space is typically used to house the Agile wall, big visual charts, user stories, task cards, the RIO, and other artefacts as required.


WAgile is a hybrid of Waterfall and Agile approaches to delivery. Often, waterfall projects encounter difficulties when the project realises that what was designed 6-18 months ago, is no longer relevant or applicable, but due to the nature of their project, their organisation's appetite for change, along with a multitude of inflexible processes, they decide to adopt some Agile techniques in a desperate attempt to save the project. You will recognise these projects as they will most likely have an Agile wall, they will perform daily stand-ups and will probably be operating in fortnightly iterations. The vast majority of the agile principles however will not be in place, the business will not be receiving bundles of value every fortnight, there will be minimal refactoring, and even less honest retrospectives.

Wisdom of the Crowd

Wisdom of the crowd is the process of taking into account the collective opinion of a group of diverse individuals rather than a single expert to answer a question. A large group's aggregated answers to questions involving quantity estimation, general world knowledge, and spatial reasoning has generally been found to be as good as, and often better than, the answer given by any of the individuals within the group.

An intuitive and often-cited explanation for this phenomenon is that there is idiosyncratic noise associated with each individual judgment, and taking the average over a large number of responses will go some way toward cancelling the effect of this noise. Social information sites such as Wikipedia and Yahoo, while not new to the information age, have pushed this process into the mainstream spotlight! Answers, Quora and any other web resources that rely on human opinion. The process, in the business world, was detailed by James Surowiecki in his book The Wisdom of Crowds.

Work in Progress (WIP)

Refers to work that is currently being done. Helping the core team members understand the collective WIP is one of the underpinning reasons why stand-up meetings are held frequently.

Work Packet / Work Package

Is a chuck of activity that is undertaken to achieve an outcome or complete an artefact. Work packets (also known as work packages) are typically captured on task cards and tracked on an Agile wall.

Back to top