Specific conditions or requirements must be met for a user story or feature to be considered complete and accepted by stakeholders.
The practice of entirely focusing on and comprehending what others are saying, not just hearing the words, but also understanding the underlying meaning and context.
A leadership approach that emphasizes flexibility, collaboration, and the ability to adapt to changing circumstances and complexity within an organization or team.
Adaptive Software Development
A software development methodology that promotes iterative and collaborative development, focusing on learning, feedback, and continuous adaptation to deliver high-quality software. Based on the Shewert cycle of plan-do-check-act
Referring to Lyssa Adkins, an Agile coach and author, Adkins guidelines represent the four pieces of groundwork to set in place before one-on-one coaching commences as follows:
- Meet them a half-step ahead
- Guarantee safety
- Partner with managers
- Create a positive regard
A technique used in Agile planning and estimation, where items or user stories are grouped based on their similarities or shared characteristics, allowing for more efficient and accurate estimation.
A way to visualise the work being done by the agile team. Often used in Kanban systems to see the work in progress at each stage of the system. This is an example of an Information Radiator.
The person who helps the team, department or organisation understand the values, principles, practices and mindset of agile approaches. In an agile team, the agile lead (the scrum master for scrum teams) is accountable for coaching that team.
The process of helping teams, departments and organisations better understand agile values, principles and mindset, as well as the specific practices of agile methods.
The manifesto for agile software development was created in 2001 to summarise the approach taken by the creators of agile frameworks. It highlights the need to put emphasis on the:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan
Agile Modelling (AM)
An approach to modelling software that encompasses a set of values, principles, and practices. It offers a lightweight and effective way to apply modelling techniques in software development projects. The 5 values are: Communication, Simplicity, Feedback, Courage, and Humility.
Whereas traditional planning tends to predominantly be done upfront based on a fixed Scope, Fixed Cost and Fixed Timeframe. Agile planning is constant, more flexible and at multiple levels with the most detailed planning created for the most immediate work and the plan is checked and adjusted often. Rolling Wave planning is a popular technique
Refers to the application of agile principles and methodologies, such as Scrum or Kanban, in managing and delivering projects, emphasizing iterative development, collaboration, and adaptability.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
A common solution or approach to a problem that appears to be helpful, but ultimately leads to negative consequences or poor outcomes, often contrary to established best practices.
An architectural spike is a time-limited investigation conducted by a development team to address uncertainty or risk associated with a specific architectural challenge. It involves conducting experiments or research to gain insights and validate potential solutions. The results from the spike inform decision-making and guide the architectural direction of the project, minimizing risks and ensuring alignment with project goals.
ASD is Adaptive Software Development and is a progression from RAD. The Adaptive development cycles are mission-focused, component-based, iterative, time-boxed, risk-driven, and change-tolerant.
Automated tests are scripted tests that run automatically. These are often included in a continuous deployment pipeline where they run every time code is committed and, if the tests fail, prevent the deployment of faulty code. Often built into a comprehensive regression test suite to ensure new changes do not cause defects in established code.
The activity of adding additional detail and analysis to items on a product backlog. This often includes:
- Estimating the effort
- Adding acceptance criteria
- Managing dependencies
These activities may be done by individuals, small groups, or by the whole team. They are usually carried out during an iteration/sprint, for work coming up in the future.
An ordered list of items to be completed. Backlogs should be visible so that they can be inspected and adapted. In Scrum, there are two backlogs, one representing future work (Product Backlog) and current work (Sprint Backlog).
See Backlog refinement
Behaviour Driven Development (BDD)
A form of acceptance criteria that allows technical and business people to define how a system should behave in a range of specific scenarios. Tests are based on scenarios, operating at a functional level and fulfilling a similar job to traditional regression tests.
The format for each scenario is:
Given <A set of preconditions, context, or starting point>
When <An action occurs>
Then <The system should respond in this way>
Big Bang Delivery
A software development approach is where a complete system or a significant portion of it is deployed and delivered all at once, typically without incremental or iterative releases.
Big Room Planning
A collaborative planning technique used in Scaled agile methodologies where multiple teams, stakeholders, and product owners come together in a single physical or virtual room to coordinate and align their work for upcoming iterations or releases.
A group session to overcome a problem or achieve a goal. Sometimes facilitated using a framework such as Strengths Weaknesses Opportunities Threats (SWOT) Mind mapping or de Bono’s Six thinking hats
Burn down chart
A Burn done chart tracks completed work done by the team daily during the sprint. Its rate of descent can prompt useful questions in team sessions regarding progress. A burn-down chart usually only shows a single sprint. If the team complete everything in their Sprint Backlog the line would track down to zero. The amount of work completed in a sprint is termed Velocity (See separate entry)
Burn up chart
A Burn-up chart is a liner chart similar to the Burn Down Chart but usually covers multiple sprints. It shows the cumulative work completed each sprint by the team so that the line “Burns up” to a total amount, which represents all of the work required to be done for the product. This can be useful to forecast completion dates when the line will “cut” the total threshold and also the impact of increasing or decreasing the total scope on the timeline.
The rhythm of events in an agile team is typified by events taking place at regular, predictable intervals. For example, Sprint Planning takes place every two weeks on a Wednesday morning.
An activity undertaken by a team before they start sprinting to agree on the five Whys and How of the Project: What they aim to achieve, Why the work needs to be done, Who will be involved in this work When it needs to be delivered by, Where this work will take place and HOW they intend to work together.
Chicken and the Pig
This is an analogy used to highlight different levels of commitment in agile. In this fable, the pair decide to open a restaurant called “Ham and Eggs”
The chicken is involved, but the pig is fully committed, and willing to make sacrifices for the project’s success. It highlights the importance of high commitment in achieving successful outcomes.
Agile working requires high levels of communication and team interaction. Having the team Co-located in the same physical space may be the ideal scenario but is increasingly difficult to achieve. Modern digital tools can offset many of the issues of the new norm of remote working
These ate facilitated events with activities designed to encourage stakeholders and the agile team to share views and actively participate in decision-making. Examples include “Prune the Tree” and the “Sailboat/Speedboat” exercise
A specialized team within a larger development effort that focuses on developing and maintaining specific components or modules of a software system, often working closely with other teams to integrate their components into the overall solution.
A visual representation that illustrates the boundaries and interactions between a system and its external entities.
Cone of Uncertainty
This is a concept used to explain how at the start of a piece of work, estimates and forecasts are often likely to be highly inaccurate for Complex work. As time passes and work progresses it is expected that inaccuracy narrows (like a cone) and forecasts made at that time are more accurate than previous estimates.
Conflict and disagreement are a natural and even sometimes beneficial result of intelligent teams resolving complex problems. However, we must ensure that conflict does not escalate beyond a simple difference of opinion into something that threatens the team’s stability and effectiveness. In that case, facilitation to help parties see each other’s point of view and collaborate on a compromise may be required. See Speed B. Leas’ 5 levels of conflict.
Continuous Deployment (CD)
An automated process where completed code is automatically tested and deployed to the various technical environment such as testing, staging or production. Usually combined with Continuous Integration and Automated Testing, which must be passed before the deployment takes place.
Continuous Integration (CI)
An automated process where completed checked-in code is picked up by an integration build machine and the results are fed back to the development team. Often used in conjunction with Automated Testing.
States “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure… therefore, flexibility of organization is important to effective design.” This can be interesting as, The work a team or organisation produces often reflects the structure of the organisation and how people communicate with each other.
An agile methodology from the early 90s and still in use today. It consists of a family of colour-coded approaches (from Clear through to Sapphire) depending on the size of the team and the criticality of the project.
Cumulative Flow Diagrams (CFD’s)
A graph that gives an overall picture of the total work DONE over time and the average work in progress (WIP) at any time. From this, Average Throughput and Average cycle time can be derived. Indicating trends over time and potential bottlenecks to the efficient flow.
Customer value prioritisation
Understanding what is most valuable to the customer and using this information to order the backlog of work.
The elapsed time from when a piece of work was started to be worked on until it is completed (Done). This is therefore always shorter than Lead time which commences when a work item is known and recorded but not necessarily started.
Also known as the daily stand-up or team synchronisation meeting, the purpose is for the team to inspect progress towards their goal, share relevant information, and adapt their plan as necessary. The timebox for this event is typically 15 minutes and takes place at the same time and place every 24 hours.
Daily Stand-up Meetings
See Daily Scrum
A principle is that agile teams Delay committing to decisions until the last responsible moment. To avoid restricting options prematurely
Declaration of Interdependence
The Declaration of Interdependence is a set of six management principles created after the Agile Manifesto. The principles are:
increase return on investment by — making a continuous flow of value our focus.
deliver reliable results by — engaging customers in frequent interactions and shared ownership.
expect uncertainty and manage it through — iterations, anticipation and adaptation.
unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
boost performance through — group accountability for results and shared responsibility for team effectiveness.
improve effectiveness and reliability through — situationally specific strategies, processes and practices.”
An acronym used to describe attributes of a good Product Backlog
D: Detailed appropriately, E: Emergent, E: Estimated, P: Prioritised
Defects or bugs or errors are inevitable. They can be categorised as either Commons causes – The natural variation inherent in all work, or as special causes, an outside influence that has caused the defect. Most importantly an agile team seeks to find the root cause and address it.
Definition of Done (Done)
A list of criteria that must be achieved by the agile team to consider an item completed or ‘Done’. The definition of done is not item specific, must be able to be completed by the agile team itself, and needs to be specific enough so that it is clear whether it is achieved or not.
Definition of Ready
A set of criteria or conditions that a user story or product backlog item must meet before it can be considered ready for development.
Development team or Developers
In Scrum, Developers are the people who turn backlog items(requirements) into valuable products. They may have a variety of skills such as coders, testers designers etc, but Scrum classifies them all as Developers. Note that as of 2020 the Scrum guide uses the term Developers rather than Development team and describes accountabilities rather than Roles. This may not yet be reflected in PMI ACP
- Cross-functional – each member of the team has a specialism, with abilities to carry out secondary skills, with a T-shaped profile
- Self-organising – the team decides how to turn the requirements into working software, and who should do what on a daily basis
- Recommended size: 3 – 9 (Note for scrum exams use 10 or Fewer as a recommendation)
DevOps is an amalgamation of tools, techniques, and processes to align Development and Operations activities, using lean principles.
A way of arriving at a consensus between options identified in a meeting. Each participant has a set number of votes or dots which they can use to mark their preferred options(s)
A model of skill acquisition using five stages. The model serves as a framework to understand the development of skills and expertise over time. Stages are:
Novice; Advanced Beginner; Competent; Proficient; Expert.
Drum Buffer Rope
A metaphor using a Scout troop linked by a rope to explain concepts such as the Theory of Constraints and the need to Limit Work in Progress. The troop will only ever move at the pace of the slowest scout (This is the Drumbeat). The Scouts may pull on the rope between them (the slack in the rope is the buffer) but they will still only move as fast as the slowest scout.
Dynamic Systems Development Method (DSDM)
An agile framework from the mid-nineties is still in use today. DSDM encourages close collaboration between the project team and business stakeholders. It promotes the active involvement of stakeholders throughout the project to ensure that their perspectives and requirements are continuously considered and incorporated into the solution.
A very high-level statement, giving the reasons for the work and value expected. So-called because it should be able to be delivered in the time it takes to ride an elevator.
Allowing the technical design to emerge during the development process so information learned can be applied to the design. This is the alternative to a traditional Big Design Up Front (BDUF) model.
Emotional intelligence is the ability to recognize, understand, and manage emotions, both in oneself and in others, to navigate social interactions and build effective relationships.
A visual tool used to understand and empathize with users or customers by capturing their thoughts, feelings, behaviours, and needs in a structured manner.
Empiricism/Empirical Process Control
A principle of empirical process control in agile methodologies, emphasises that knowledge and decisions should be based on observations, experimentation, and evidence rather than assumptions or speculation.
EMV – Expected Monetary Value
Expected Monetary Value (EMV) is a statistical technique that calculates the potential value or Risk of uncertain outcomes by multiplying the probability of each outcome by its associated monetary value or Cost. E.G. If an event has a potential cost of $200 and a 10% likelihood of occurring, its EMV is $20
There are many frameworks and approaches to scale scrum to a large scale utilizing multiple teams working together. Some of these are: SAFe, LeSS, and Nexus. Many of the core scrum events are usually scaled up such as Scrum of Scrums Etc.
This term describes a large piece of work, often comprising of multiple value statements, user stories etc. They are grouped together under one overarching description. Usually, epics are too large to be worked on without breaking them down.
The process of forecasting the size of different items of work on a backlog. Agile teams often use relative sizing and story points. Techniques used for estimation include Planning Poker and Wide-band Delphi. An important aspect of estimation is the team conversation which leads to an agreed estimate
An Open Standard for software engineering that provides a common language and set of practices to describe and assess the essence of software development.
EVM – Earned Value Management
A project management technique that integrates cost, schedule, and scope to assess project performance and forecast future progress by comparing planned and actual values. EVM is expressed as a percentage or a decimal. Greater than 1 is good and means the project is ahead, less than one signifies the project is behind schedule or has delivered less value than expected.
Extreme Programming (XP)
An agile framework similar to Scrum with an emphasis on technical excellence and close customer collaboration.
A positive expression used in Agile to indicate that if something is not feasible or potentially not valuable, then an agile approach will find that out quickly and prevent wasted effort.
A distinct capability or functionality provided by a software system or product that delivers value to users or stakeholders.
Feature Driven Development (FDD)
An iterative and incremental software development methodology. It focuses on designing and building software features in short, time-boxed iterations. FDD emphasizes collaboration, domain modelling, and feature-based planning to deliver valuable functionality incrementally throughout the development process.
A cross-functional team composed of members with different skills and expertise working together to deliver end-to-end features or user stories.
A specific statement that describes the desired behaviour or functionality of a software system or product.
A series of numbers in which each number is the sum of the two preceding ones. 1,2,3,5,8,13,21,34,75, Etc. It helps in estimation techniques like Planning Poker by assigning story point values. The sequence’s gaps aid in selecting estimates and streamlining the estimation process.
Fishbone Diagram – Ishikawa diagram
A technique to help expose the reasons behind a certain effect of the defect. The fundamental question, e.g., the defect, is the Head of the fish and possible causes such as Resourcing, technology etc branch off from it like the bones of a fish helping to drive enquiry
A technique to help teams look deeper and find the root cause of an issue. It is performed by asking “Why” five times. With the question “why” being asked of each preceding answer, e.g., “Why was bug no detected, because the software was out of date, why was the software out of date, because procurement hadn’t approved the purchase order, Why hadn’t Procurement…..etc.
A chart is typically used in traditional project management, not agile teams. It shows progress against tasks over time and dependencies.
A member of an agile team who is highly skilled in at least one area but has enough capability in other areas and can assist the team if that is a key task to meet the team’s goals. For example, a specialist front-end developer can also write some automated testing scripts or do some database work. Also known as a ‘T-Shaped Professional’.
Gulf of Misunderstanding (Gulf of Understanding)
This is a term to describe a potentially dangerous situation when the agile team and stakeholders are not aligned and on the same page. Sometimes even the customer will admit that they don’t know what they want until they see it. Frequent check-ins and validation of the work done to date with stakeholders are required to mitigate this.
History of Agile
1948: The Toyota Way was codified, taking inspiration from a U.S. Grocery store, marking the beginning of the Lean movement in manufacturing
1995: Scrum was presented publicly for the first time, at the OOPLA conference
2001: A group of thought leaders created the Manifesto for Agile Software Development
A fictional amount of time that something would take if you were able to concentrate solely and fully on that one thing. This is almost never the case. Agile teams. Understand that there are mistakes and interruptions and do not plan using ideal time.
A potentially releasable piece of work. In Scrum, this is one of the artefacts and represents the output of the latest sprint combined with all previous Increments.
A physical (or electronic) display of information that is designed to allow interested parties access to that information without the need for a team member to specifically relay it. Examples include Agile Boards, digital displays showing service availability or the state of the latest software builds.
A retrospective, but one that takes place as needed during the sprint in reaction to a particular event or issue, with a view to inspecting and adapting in order to overcome the issue and learn from it.
A mnemonic to help set standards for the quality of analysis for product backlog items. By the time a backlog item reaches the point where it may be discussed at Sprint Planning, it should have the following characteristics:
- Independent – the item should not rely on future work to be worth building
- Negotiable – developers should be able to propose alternative solutions to deliver the capability needed
- Valuable – the value that an item brings should be defined and understood by all
- Estimable – it should be possible to forecast the amount of effort needed
- Sized appropriately – small enough for several items to be completed in one sprint by one team
- Testable – it should be clear to all when an item has met the requirements
IRR – Internal Rate of Return
A calculated percentage which expresses the value of your return in the future allowing for inflation. A higher IRR is better.
A timeboxed and repetitive development cycle in Agile methodologies, where a subset of features or user stories is implemented, tested, and reviewed within a fixed time period. In Scrum, this is a Sprint
A foundation or setting up sprint of indeterminate length to establish the team and ways of working prior to the first sprint. Note the concept of a sprint Zero is not supported by Scrum.org
A special sprint to complete or finalize work to make it ready for release to production. For example, extra testing, documentation etc. This is not a concept supported by Scrum.org which believes every sprint should deliver a potentially releasable valuable increment of the product.
See Sprint Planning
See Sprint Review
A Japanese term referring to continuous improvement in processes, products, and services by making small incremental changes over time.
A method of managing the flow of valuable work. The principles of Kanban manage and improve work across systems. It is not limited to software and has no constraints or timeboxes. Work is limited by a pull system: new work can only enter when a space is made by completed work leaving the system. A Kanban board visualises work.
A prioritisation technique, used to categorise requirements or user stories into four groups Exciters (extra features that excite customers, Satisfiers (expected features), Dissatisfiers ( features that if missing will disappoint the customer), Indifferent features (those features the customer is not interested in).
Key Performance Indicators (KPIs)
Organisational goals that give guidance and help teams with the alignment of work towards agreed objectives
A metric capturing the elapsed time from when a requirement was initially recorded to when it is finally delivered. This is usually longer than Cycle time which only commences once work on the requirement has begun.
Lean software development
An adaptation of the lean principles developed in manufacturing to make them relevant to software, taking the form of seven principles:
- Eliminate waste
- Build in quality
- Create knowledge
- Defer commitment
- Deliver fast
- Respect people
- Optimise the whole
See Seven Wastes of Lean
Large-Scale Scrum (LeSS)
An enterprise or scaled framework for multiple teams working on a single product and all using Scrum (unlike SAFe). It has 10 guiding principles.
Larman’s Laws of Organisational Behaviour
Developed by Craig Larman, they highlight key observations and insights about how organizations operate in an Agile context. These laws aim to guide and shape effective Agile adoption and transformation within organizations. Examples include Organisations being implicitly optimised to avoid changing the status quo and Organisational Structure influencing the culture. To change the culture, you must change the Organisation structure.
Likely Costs remaining
An agile project management metric calculates the costs still outstanding by multiplying the cost per sprint by the number of expected remaining sprints required to deliver the product.
Mean Time to Restore
One of the possible value measures. A metric that measures the mean (average) time to recover after an incident.
Minimum Marketable Product (MMP) or Minimum Marketable Feature (MMF)
The smallest set of features will give early value to the customer and validate the product’s worth. An early minimum release to gain feedback and possible ROI
Minimum Viable Product (MVP)
A version of a product that includes enough core features and functionalities required to run as an experiment and gain valuable feedback
A communication technique where one party matches the mannerisms and body language of the other party to build rapport and empathy.
When many people crowd round a single computer to work out a tricky problem. It is good for preventing blockers that would otherwise take time to resolve. Sometimes referred to as ‘swarming’.
A prioritisation technique used as an alternative to Dot voting or MoSCoW played with the team and stakeholders. Each stakeholder has a fixed amount of play money to ‘buy’ the features they want most. Those features or stories have all been assigned a price. Prioritisation is based on the features/stories that have the most funding.
The practice of planning an agile project with a backlog of features, and nominating each item:
- Must have
- Should have
- Could have
- Won’t have (this time)
Muda, Mura, Muri
Japanese expressions from the concept of Lean thinking. Muda – Waste. Mura – Uneven flow of work. Muri – Overburdened workers or equipment
Net Present Value (NPV)
The most important of project financial forecast metrics. NVP is the result of the present value of cash input into the project against the present value of cash outflows utilising the IRR and payback period to calculate this. NPV is a decimal number above 0 that is profitable, below zero is not profitable.
A specification that describes the characteristics, qualities, or constraints of a software system, such as performance, security, reliability, or usability.
The process of absorbing information just being in the same physical space and observing or overhearing things.
Two team members working on the same computer to build a feature. One person ‘drives’ and the other person navigates, collaborating and watching out for errors.
The 80/20 rule. A ratio is often used to describe how just a few things contribute much more than others. E.G., 20% of the features delivered 80% of the value, or 80% of defects arise from just 20% of the code.
Used to calculate NPV and ROI. It is the amount of time taken to before income from the product exceeds the costs of the project and we start to show a profit. The shorter this period is the sooner we generate a profit.
An agile game used by coaches and trainers to demonstrate to agile teams the principles of flow and limiting work in progress. The game is played by team members passing vary size batches of coins to each member in turn after having flipped them over.
Plan, Do, Check, Act is an iterative, four-stage method to repeatedly improve a product, service, or process.
A fictional character or archetype that represents a specific user or customer segment, is created to understand their goals, behaviours, needs, and motivations in the context of product design and development.
A way of allowing a diverse team of estimators with different specialisms to apply story point estimates to items:
- Each item is discussed
- Individuals estimate individually using cards without seeing what their teammates picked (to avoid anchoring bias)
- Everyone turns over their card simultaneously
- Differences in opinions are discussed, enhancing the shared knowledge of the team.
- A final number is agreed upon based on the shared information
A Japanese term which means “error proofing” Building in process steps that prevent mistakes from occurring such as warning messages or design features.
An ad hoc end-of-project meeting to discuss what happened on the project and what lessons might be learned.
A risk analysis meeting at the start of the project for the team to consider all the things that ‘might’ go wrong. This is called ‘remember the future’.
A technique used to compare the wasted time in any given process as a percentage of the overall time taken. E.G., 20 minutes wasted in a 40-minute meeting would be 20/60 = 33% This waste is commonly visualised via a Value Stream Map
The idea of taking concepts from various frameworks and creating a hybrid model. It is generally best to fully understand and use one framework before attempting to integrate elements from other frameworks. This follows the guidance of Shu Ha Ri.
A traditional fixed scope fixed price approach to procurement and contracts is an inhibitor to agile ways of working. If possible, a Time and Materials contract offers far more scope for incorporating inevitable change. There are options such as swap in/swap out, and early termination clauses that allow traditional procurement more flexibility.
An ordered list of items to be done to enhance or maintain a product. Items at the top of the list, which are likely to be worked on first, have had the necessary analysis for them to be worked on by the team. Items lower on the list will have had less analysis.
A Scrum role. Defines what is to be delivered, and released, and optimises the overall value of the product. Desirable characteristics follow the DARKA model:
- Desire to be involved in the product
- Authority to make decisions
- Responsibility for the outcomes of those decisions
- Knowledgeable about the product, users, and market
- Available to the team to clarify requirements and make plans
A timeboxed period in SAFe (Scaled Agile Framework) where multiple Agile Release Trains (ARTs) work together to deliver a set of features and incrementally build a larger solution.
A major stakeholder in the organisation, perhaps one who is financially backing the project. They would expect to be closely involved and attend Sprint Reviews.
A high-level view of the aims of the project, the problem trying to be solved, and the opportunities and benefits to the organisation and customer. Created by the product owner and shared with the team and stakeholders.
A process of adding detail to the Product Backlog and reordering it on an ongoing basis as that information and detail become available.
Prune the product tree
A collaboration game to visualize requirements of user stories on a trunk and branch diagram. Showing features which are core MVP on the trunk and others which will be a part of later releases, the branches.
A shared belief held by members of a team that the team is safe for interpersonal risk-taking. It allows team members to be vulnerable in front of each other, for example by asking questions where they may otherwise be perceived as ignorant for not knowing the answer. A key ingredient for high-performing teams.
Purpose Alignment Model
A four-quadrant chart based on two axes Market Differentiators and Mission Critical. It is used to understand which activities are most important and should be focussed on. The quadrants are: Partners, Who Cares? Parity, and differentiation.
The process of optimising and cleaning up code without changing the functionality. A key element in Test Drive Development (TDD). Refactoring helps reduce technical debt.
A process where items are estimated in comparison to each other rather than given absolute values. Story Points are often used when conducting relative sizing. Alternative options include ‘T-Shirt Sizing’, where items are grouped into Small, Medium, Large, etc.
The process of forecasting when a set of features will be delivered or, for a fixed date, which feature will be completed by the required date.
A meeting to look back and identify possible improvements to how the team performs regarding quality, tools, process and collaboration. For Scrum, see Sprint Retrospectives.
Return on Investment (ROI)
A ratio comparing the benefits received against the money invested. E.G., a $4000 return on an outlay of $1000 has an ROI of 4:1
A formal statement that specifies what a software system or product should do or how it should behave, typically derived from user needs or business objectives.
Using risk analysis to help the product owner order the backlog considering the relative risk of each item perhaps using EMV to quantify it.
Using a variety of techniques to identify, understand and mitigate risks in a project. This will provide the Product Owner with information to assist them in ordering the backlog accordingly.
Risk Burndown Charts
A chart plotting the project’s exposure to risks over time. Ideally trending downwards. This could be shared with stakeholders at the sprint review.
A spike with the aim of approaching a known risk and identifying a method to prevent this risk from impacting the future, such as updating architectural databases or improving resilience in backup systems
A strategic plan or visual representation that outlines the high-level goals, features, and timeline for the development and release of a product or software system.
A picture metaphor used in Agile retrospectives to identify actions. The picture of the boat invites participants to add things that help (Wind in the sails) things that slow them down (Anchors dragging in the water), Risks ahead (rocks and reefs in the water) Where they want to get to (Port/Island)
A model created by Virginia Satir shows how individuals and organisations go through a cycle of change. Perhaps being moved out of the status Quo by some sort of disruption into a temporary state of chaos. The choice is then to either try to regain the original status quo or try to transform into the new normal. Originally designed for family counselling it is equally applicable to organisations undergoing transformational agile change
Scaled Agile Framework (SAFe)
A popular framework for applying Scrum to Teams of Teams working together. It introduces different models depending on the scale and new events and roles.
An agile product delivery framework comprising 3 roles, 5 events, and 3 artefacts and 5 values based on empirical process control. Work is limited by fixed-length sprints of 30 days or fewer.
A hybrid approach incorporating elements of Kanban into a Scrum-like framework. Also used as a derogatory term for a term that is doing neither framework correctly and missing vital elements of both.
A Scrum role. Responsible for the process, facilitates and coaches, and resolves impediments. Desirable qualities:
Servant leader for the team, guiding without direct authority
Enables the other roles to be effective without making decisions on their behalf
An event where representatives from different Scrum teams meet to collaborate and coordinate the integration of work across their respective teams.
Scrum Team Member
The scrum master, product owner or a member of the scrum development team. These are the people who plan and do the work in the team.
Scrum Three Pillars
Scrum is built on empirical process control on the basis that complex work is best managed through a process implementation:
- Transparency over the plan and progress made so far
- Inspection of the plan and the process based on the most up-to-date information
- Adaptation of the plan and process with a goal of maximising the value delivered
Scrum implements transparency through the artefacts, and all events enable the inspection and adaption of specific parts of the process and the plan.
Seiri, Seiso, Seiton, Seiketsu, Shitsuke — Five S:
A Lean methodology related to the team workplace, to make it an efficient and productive environment. The words stand for ‘Sort, Straighten, Sweep, Standardise, Sustain’.
Self-directed or self-managing Teams are capable of making their own decisions regarding how they work within agreed guardrails. This is the ideal aspiration for an agile coach or scrum master for a team to reach this level of autonomy
A servant leader is someone who supports the team and leads them without direct authority. The success of a servant leader is measured by the growth of the team and individuals within it.
From Lean principles the Seven waste of software development are:
- Partially done work
- Extra Features
- Task Switching
A continuous improvement cycle is used as the basis for many agile approaches: Plan-Do-Check-Act
Shu Ha Ri
A concept originating from martial arts that represents the stages of learning and mastery, It represents the evolution from initially following prescribed practices (Shu), to adapting and customizing them (Ha), and finally, reaching a state of self-directed mastery and innovation (Ri).
An Acronym for creating good goals or KPI’s.
S – Specific
M – Measurable
A – Achievable
R – Realistic
T – Time-Bound
A way to help a group consider and identify different types of risk
S – Sociocultural
P – Political
E – Economic
C – Competitive
R – Regulatory
U – Uncertainty
M – Market
A time-boxed task or experiment undertaken by a development team to gather information, explore a problem, or assess the feasibility of a solution before committing to a full implementation. There are different types such as Architectural and Risk Spikes.
A scaling model originating from Spotify. Lightweight and not aligned to using Scrum or Kanban solely. Teams are called squads with communities of people with the same skills formed into cross-team groups called Tribes and Guilds.
A fixed period of not more than 30 calendar days during which an agile team deliver an increment of work. A Sprint is one of the five events in Scrum.
The list of tasks to be completed in a single Sprint/iteration. The team decide how many items to look to complete during the sprint and break the work down into tasks, which go onto the sprint backlog.
A Scrum event where the whole team get together to make a plan for the next sprint. The product owner brings the product backlog with items at the top in a suitable state to plan. Each item is clarified before the development team break it down into a detailed plan. The timebox for this event is typically 8 hours for a 4-week sprint.
Also known as the iteration retrospective, the purpose is to allow the agile team to inspect and adapt the process based on their experiences in the last sprint. The whole team identifies what went well, and what didn’t go well, before committing to at least one specific, actionable improvement to take into the next sprint. The timebox for this event is typically 3 hours for a 4-week sprint.
Also known as the iteration review or show & tell, the purpose is to allow collaboration between the agile team and the business. The work completed is inspected along with the current product backlog and release plan. All parties participate in giving feedback and discussing options with a view to adapting the product backlog and improving the plan based on new information. The timebox for this event is typically 4 hours for a 4-week sprint.
Squads termed from the Spotify scaling model are small cross-functional teams typically fewer than 8 that have a single focus or mission. They typically have an agile coach to guide them and a product owner to provide product direction. Unlike scrum teams, squads can use any agile framework they choose.
Any individual, group, or organization that has an interest or involvement in a project, product, or system and can influence its outcome or be affected by its results.
A visual technique often used in Retrospectives to capture things to: Stop doing, start doing, keep doing, things the team want more of, and things they want less of.
Teams size items relative to each other, in arbitrary units not directly tied to duration. The most common scale used is the adjusted Fibonacci sequence:
1, 2, 3, 5, 8, 13, 20, 40, 100
Working at a pace that can be sustained over the long term. Practices include working to a standard 8-hour day and under planning so that there is minimal reliance on overtime or similar. This generally results in less burnout, fewer defects and fewer project delays.
When multiple members of a team all focus on a single issue or piece of work to get it completed as soon as possible
SWOT (Strengths, Weaknesses, Opportunities, Threats)
A brainstorming event, used in risk identification and analysis.
The drum beat or rhythm of delivery items which the team need to keep to in order to deliver on time.
The team agreement or charter on the ways of working agreed by the team themselves. The ground rules.
A term used to describe the accumulation of code that is difficult to maintain or scale. Over time as code is amended or components are on older unsupported versions this will often slow down future development. This code debt needs to be paid back by frequent tidying and updating – Refactoring
Test Driven Development (TDD)
A technical form of testing usually done by software engineers themselves, involves writing a failing unit test, then writing just enough code to make it pass, and then refactoring to improve the code.
The largest unit of work in an Agile project. Above Epics. The Theme is the strategic initiative and helps define the Vision and goals below it in the hierarchy
Theory of Constraints (ToC)
This theory says that all systems will have some sort of bottleneck that is the overriding constraint to the flow of work. Often this can be identified by work queueing up just before the bottleneck. Teams should aim to remove bottlenecks if the flow is insufficient. The constraint will then move to the next most constricting factor.
A Kanban lagging metric that measures the average number of work items completed in a given period. It can be a useful alternative to Velocity.
Based on temporal motivational theory, a timebox is the maximum amount of time permitted for an activity, creating a sense of pressure to complete the work. It is the fixed amount of time allotted for an iteration or sprint of development. For example:
- In Scrum, the maximum amount of time for Sprint Planning is 8 hours. It doesn’t have to take that long but can’t take longer.
- Iterations or Sprints have fixed timeboxes, which are chosen at the start and are typically kept the same length every time. If the team chooses a 2-week sprint, then more work is added if they finish early, and any incomplete work is put back on the backlog if not done within the 2 weeks.
An estimation technique, comparing a user story against two other similar user stories
The iron triangle of balancing Scope Time and Cost. In waterfall approaches, the Scope is fixed and Time and Cost are adjusted to deliver that Scope. In Agile, Time and Cost are fixed, and the Scope is adjusted accordingly.
A technique for generating ideas, commonly used in retrospectives. Each person has five minutes to write down some ideas, then pass to the person next to them to take 5 mins to add to and build upon those ideas. This continues until the papers are back with each originator.
Tuckman’s Model or Ladder
A description of the phases of team development transitioning from Forming to Storming to Norming to Performing. Note that changes to team membership and other outside influences can cause a team to regress to a previous less productive stage.
A security measure that requires users to provide two forms of authentication (such as a password and a unique code from a mobile app) to verify their identity and access a system or service.
See Generalising Specialist.
A description of interactions between actors (users or systems) and a system to achieve a specific goal or result, is often represented as a narrative or a diagram.
Use Case Diagram
A visual representation that illustrates the relationships between actor’s use cases, and the interactions within a system or product.
A defined set of permissions, privileges, or responsibilities assigned to a user within a system or application, determining their access and functional capabilities.
A simple but incomplete way of expressing requirements on a product backlog to allow the high-level intent to be understood and to foster a conversation between developer and customer. They contain just enough detail to decide how to prioritise, and whether to start analysing further. The most common format is:
As a <Role>
I want <Functionality>
So that <Benefit or value>
User Story Mapping
A technique used in Agile product development to visually organize and prioritize user stories, creating a coherent representation of the product backlog and user flow.
User Experience Design focuses on enhancing user satisfaction by improving the usability, accessibility, and overall interaction between users and a product or system.
Value Stream Mapping
Visualising the Team’s processes and identifying waste: activities that do not add value. Thus, allowing the team to change their ways of working in an effort to improve flow and reduce cycle time.
Variance and trend analysis
Variance is measuring how different things are from our estimates or expectation. Trend analysis is a review of data over a period to identify tendencies
A historical performance metric that shows how much functionality was delivered at the end of previous sprints/iterations. Usually measured in story points, and used by:
- Product owners to predict release dates for items on the product backlog
- Development teams to predict what they can deliver in the next sprint/iteration
Identifying thin slices of the product that can be delivered incrementally to deliver value. Each slice comprising of all required components e.g., front end, back end, data storage etc. The alternative is Horizontal slicing where a layer of work is completed such as Front end, but no end-to-end functionality is delivered.
A type of Software Development Life Cycle (SDLC) model where the process starts with Requirement Analysis and then does through System Design, Architecture Design, Module Design, Coding, Unit Testing, Integration testing, System testing and Acceptance testing. Depicted in a ‘V’ shape with ‘Coding’ at the base. The idea is that the analysis gets increasingly detailed, then it is coded, and the testing starts very granular and completes with the acceptance tests. A traditional, non-agile model.
Volatile, Uncertain, Complex and Ambiguous (VUCA)
Agile approaches are likely to achieve better results than traditional approaches for work that displays VUCA characteristics.
- Volatility – Things are likely to change rapidly without warning
- Uncertainty – There is a lack of information available
- Complexity – There are many interconnected variables and decisions to manage
- Ambiguity – Available information is difficult to interpret
An example of a defined process is where projects are delivered in large stages or batches. All of the analysis is done, followed by all of the design, coding, testing, etc. A high-risk approach in a VUCA environment.
A consensus-based estimation technique that involves a group of experts independently providing estimates for tasks or project components, followed by group discussion and iteration to converge on a final estimate. Used in Planning Poker.
A software product or system that is functional, meets the specified requirements and provides value to users or stakeholders.
Work in Progress (WIP)
A Kanban metric measuring a number of everything currently being worked upon. Kanban theory and Little’s Law state that lowering the Average WiP should reduce the average cycle time. Therefore, teams often impose limits upon their total WiP
An agile framework used for software development and the origin of many well know agile practices such as refactoring, Test Driven Development and Pair Programming.
 ‘Planning Poker is a trademark of Mountain Goat Software