Navigating Agile project management can be overwhelming for traditional project managers stepping into a fast-paced, iterative environment. To ease the transition, we’ve compiled a comprehensive list of over 100 Agile tools and techniques that are commonly used across industries. This resource is designed to demystify Agile practices, clarify terminology, and provide practical insights that help new project managers understand what to expect when collaborating with Agile teams.
Whether you’re managing sprints, facilitating stand-ups, or exploring backlog grooming, knowing the language and tools of Agile is essential for success. From frameworks to facilitation techniques, this guide is your go-to reference for mastering Agile. Let’s dive into the tools and techniques that make Agile thrive
Agile Planning
Agile planning is also known as progressive elaboration, which is the process of elaborating in detail just-in-time. Details are added as the project progresses and the information is required. For example, a user story will be high-level at the start and then refined so it is prepared to be added to the backlog, and then, before it is added to an iteration, it will be estimated and examined in detail. Even when the story is being worked on, details can be provided by the business, filling in more information when required.
Product Roadmap
A product roadmap is a strategic planning document that aligns both short-term and long-term business objectives with corresponding development solutions. Typically managed by the Product Manager who serves as the business representative, the product roadmap maintains consistency across project management methodologies—whether implementing Agile or Waterfall approaches. Upon completion, the roadmap is distributed to all members of the product team to ensure organizational alignment and transparency.
>> More Info on Product Roadmap by Atlassian
Iteration & Release Planning
Release planning is done before any iteration planning. The release is planned for a meeting where all stakeholders are represented to ensure their priorities are clearly expressed. The goal is to determine which stories will be delivered in the next release. During release planning, the following will occur:
- Assess the prioritised backlog and the estimates on stories.
- Sort the stories by release.
- Refine the roadmap for the upcoming release.
At the end of the meeting, there will be a clear understanding of the release goal and what stories are to be delivered within the release. The iteration planning is then done by the development team, the product owner, and other stakeholders/subject matter experts as needed. Compared to the release planning, iteration planning is a lot more detailed, and the estimates will be a lot more accurate. The customer’s role will be limited to answering questions for the development team. The Product Owner will start the meeting by describing what they want in the iteration. The development team then commits to what they think is achievable in the iteration. Always remember:
- The Product Owner has the final say on the priorities for the iteration
- The Development Team has the final say on the amount of work to be done in an iteration.
The iteration planning process will follow this process:
- Discuss user stories in the backlog
- Select user stories for the backlog
- Define acceptance criteria and write acceptance tests
- Break down user stories into tasks
- Estimate the tasks.
>> More Information on Iteration Planning by Lucid Spark
Story Mapping
Story mapping is used to categorize stories into functionality. This makes it easier to identify missing stories and prioritize stories. Grouping stories by feature is also called Epics, but story maps are different, as they help schedule stories into iterations. Once you have the sprints planned, it makes it very easy for the business to see the plan and understand what is going to be done when. Obviously, with Agile, this should be kept high-level, as nothing should be set in stone.
User Stories
A user story is a tool used in Agile development to describe software requirements. User stories are initially written out by the business and then elaborated on by developers. User stories are written out from an end-user perspective. The format for writing out a user story is as follows, which would be written on an index card:
As a <type of user>, I want <requirement/feature>, so that <purpose/reason>
Next, after you have a bunch of index cards with user stories on them, you might presume that the next step is to add all details, but you would be mistaken. Each story has 3 elements, which are called the 3 C’s – the card, the conversation, and the confirmation.
- The Card: The card is simply the index card the story is written; it represents the requirements for planning purposes.
- The Conversation: The details of the story are communicated via communication – a verbal exchange of ideas, opinions, and information between the customer and development team.
- The Confirmation: This is the customer confirming that the story has been implemented correctly.
When creating a user story, it should follow a set of characteristics which can be easily remembered using the INVEST mnemonic…
- I: Independent
- N: Negotiable
- V: Valuable
- E: Estimable
- S: Specific
- T: Timely
Kanban/Task Board
A Kanban board is a visual workflow management tool that enables teams to optimize their work processes and enhance productivity. This methodology typically employs a board structure with a minimum of three distinct columns: “Backlog” (left), “In Progress” (center), and “Done” (right). While traditionally implemented using physical sticky notes, modern Kanban boards often utilize digital platforms for enhanced collaboration and tracking capabilities.
The primary function of a Kanban board is to provide transparent, real-time communication regarding task status and workflow progression, enabling teams to identify bottlenecks and maintain continuous improvement in their delivery processes.
Free Kanban Board Templates Excel, PowerPoint, Google Sheets | Smartsheet
Agile Analysis
Wire-frames
Wireframes are used as visual representations, which don’t need any actual functionality. Some wireframes make buttons clickable to join pages together so they can be used as storyboards as well.
> More Info on Wireframes by Just in Mind
Chartering
Project Charters are used as the project’s vision, mission, and success criteria. Generally, a project charter will include a business value (Why), high-level requirements (How), and Stakeholders (Who).
>> More Info on Project Charters by Infoq
Agile Persona’s
Agile Personas are when a team uses a fictional character that has the same characteristics as the end user. This helps the help gather an understanding of the user’s approach and decision-making.
>> More Info on Personas by AgileAlliance.com
Agile Modelling
Agile modeling (AM) is a practice-based methodology for effective modeling and documentation. It is a collection of values and principles that can be applied to an agile software development project. Types of Agile models would be:
- Use Case Diagrams
- Data Models
- Screen Designs
The goal of the models is to deliver value without extraneous documentation.
>> More Info on Agile Modelling by AgileModelling.com
Workshops
Workshops are where the team can be taught new practices or software.
>> More Info on Workshops by Elabor8
Learning Cycle
A learning cycle is a concept of how people learn from experience.
>> More Info on Learning Cycle by Scaled Agile Framework
Collaboration Games
There are a number of collaboration games that help improve group communication and teamwork. The following collaboration games are compiled from the work of Karen Greaves and Samantha Laing.
Karen Greaves and Samantha Laing’s e-book, Collaboration Games (from the Growing Agile Toolbox), is available on Leanpub here: Collaboration Games e-Book Link
Broken Skype: Communication, Collaboration
Time: 20 minutes
Team Size: 8–50 people
How:
- The group cannot talk and can only use hand signals.
- The group stands in a row, passing a simple hand sign from the back to the front, one person at a time.
- Repeat the exercise, but pass a complex sign.
- Next, everyone forms a circle and passes a complex hand sign to the left. Only one person goes at a time, and the next person can correct the sign based on what they see.
Result: After the exercise, ask the team which was the most effective form of communication.
Crazy Chat: Respect, Listening
Time: 5 minutes
Team Size: 2–100 people
How:
- The group is paired up.
- One person gets one minute to stand up and speak about something they are passionate about.
- The other person is to stay seated and act uninterested (e.g., look away, check a phone, etc.).
- Then, switch roles.
Result: Afterward, ask each individual what it felt like to ignore someone and what it felt like not to be listened to.
Listening Game: Listening, Collaboration
Time: 5 minutes
Team Size: 6–20 people
How:
- The group stands randomly located in a room, ideally facing opposite directions.
- The aim is to recite the alphabet, letter by letter. If two people speak at the same time, they must start over.
- Round 2: Tell people to pause and listen before they say anything. The round will progress slower, but will get a lot further than the first round.
Result: Afterward, ask how people felt during the rounds. Ask if anyone didn’t contribute in Round 2 and how their silence contributed to the overall goal.
Movers & Shapers: Respect, Collaboration
Time: 10 minutes
Team Size: 10–100 people
How:
- Round 1 (Victim): The group is told they are to pretend to be a Victim and must silently seek out two other people: an Attacker and a Shield. They must position themselves between the Shield and the Attacker. They should do this for 2–3 minutes.
- Round 2 (Shield): Next, they are told to pretend to be a Shield and must silently seek out an Attacker and a Victim and position themselves between them. They should do this for 2–3 minutes.
- Round 3 (Triangle): Finally, they are told to pretend to be part of an Equilateral Triangle and to keep moving until their formation is perfect. They should do this for 2–3 minutes.
Result: Ask what differences they observed between each round.
- Round 1 (Victim): Participants should end up moving further and further apart.
- Round 2 (Shield): Participants should end up converging in groups.
- Round 3 (Triangle): They should come to equilibrium very quickly.
Human Knot: Self-Organization
Time: 15 minutes
Team Size: 8–100 people
How:
- The group forms two rows, and one person is designated as the Manager.
- First, the people in the front row should join their left hands with the person in the back row’s right hand.
- Then, everyone should use their spare hand to join with a neighbor. The people at the end of the rows should join hands with the person in front of them, creating a “human knot.”
- The Manager is to instruct the team on how to untangle themselves, and the team can only follow the Manager’s instructions.
Result: The group usually succeeds in a short period of time and forms a circle of joined hands.
Columbian Hypnotist: Respect, Collaboration
Time: 5 minutes
Team Size: 2–100 people
How:
- The group is paired together, and one person is chosen to go first.
- They stand across from each other. The chosen person will move, and the second person is to copy the movement for 30 seconds.
- Then, switch roles for another 30 seconds.
- Finally, ask them to instruct each other instead of copying.
Result: Afterward, ask the team which method they preferred and how they felt. This helps team members build trust and start moving together.
Non-Musical Chairs: Self-Organization, Trust
Time: 10 minutes
Team Size: 5–100 people
How:
- One person is to be the Chairperson.
- There should be one chair for every team member plus one spare.
- The group is to prevent the Chairperson from sitting on a chair without touching the Chairperson and without moving the chairs. If a team member stands, they must move and sit in a different chair.
- Give the team 1 minute to plan a strategy.
- Everyone is to move in a circle around the chairs. Tell the Chairperson to move at a steady pace, but they can change direction at any time.
- Repeat for 3 rounds or until the team finds a strategy to prevent the Chairperson from sitting for several minutes.
Result: Helps the team understand the importance of inspecting and adapting.
Collaborative Origami: Communication, Collaboration
Time: 20 minutes
Team Size: 5–50 people
How:
- The group forms pairs and is given a sheet of paper and instructions to create an origami shape.
- Round 1: The pairs sit back-to-back and try to complete the origami with one person instructing and one person folding.
- Round 2: They sit face-to-face and try to complete the origami, but the folder cannot see the instructions.
- Round 3: They sit side-by-side; both can see the instructions and what the other is doing.
Result: Great for distributed teams or to help a team understand the limitations of different communication types.
Magic Stick: Communication, Collaboration
Time: 5 minutes
Team Size: 4–10 people
How:
- The group stands in two rows and places a long, light stick (like a thin dowel or tent pole) horizontally in front of them, resting on their index fingers only.
- Their aim is to lower the stick to the ground, keeping it in contact with everyone’s fingers at all times.
Result: Get the team to realize it is much easier to achieve a goal when they work together and coordinate their efforts.
Yes, And: Collaboration
Time: 15 minutes
Team Size: 8–20 people
How:
- Round 1 (“Yes, But”): Each person has to start their phrase with “Yes, but…” One person starts a story, and the next person continues it using “Yes, but…” After a few people, the story will likely no longer make sense or will be full of conflict.
- Round 2 (“Yes, And”): Next, get people to start their phrase with “Yes, and…”
- Final Round (“Because of That”): Repeat, but people start their phrase with “Because of that…”
Result: Afterward, the team will have learned to build on others’ ideas rather than immediately shutting them down or focusing on obstacles.
Singing Clapping Numbers: Respect, Collaboration
Time: 20 minutes
Team Size: 6–100 people
How:
- The group is divided into pairs (or threes if necessary) and given three simple tasks:
- Singing: Say the words to a short, common song (like “Happy Birthday” or the “Alphabet Song”), with partners alternating one word at a time.
- Clapping: Complete a short sequence of hand claps (e.g., clap own hands, clap partner’s hands, clap own hands).
- Numbers: Count sequentially from 1 to 10, with partners alternating one number at a time.
- Round 1 (Multitasking): The facilitator tells the pairs to perform all three tasks at the same time. The facilitator shouts out a task switch command every 5-10 seconds (“Clapping!” “Singing!” “Numbers!”). When they switch, they must pick up exactly where they left off on that task. The facilitator records the time it takes for the team to complete all three tasks fully.
- Round 2 (Single-Tasking): The facilitator tells the pairs to complete the tasks sequentially. They must complete the entire Singing task, then the entire Clapping task, and finally the entire Numbers task, before moving on to the next one. The facilitator records the time it takes to complete all three.
Result: The team will almost always complete the work much faster and with fewer mistakes in the single-tasking round (Round 2). This demonstrates the high cost of context switching (multitasking) and the efficiency gained through focused work, which is critical for collaboration and flow.
123 Go: Communication
Time: 5 minutes
Team Size: 3–100 people
How:
- Tell the group you are going to count “1, 2, 3” and say “go.” When you say “go,” they should clap.
- Do it once quickly.
- The second time, pause between “3” and “go.” People will say “go” and clap too early.
- Repeat 2–3 times.
Result: This demonstrates that people have hard-wired responses (or follow their first impulse). Instead, people should take their time and think about their responses, focusing on the actual cue.
Agile Estimating Tools
Estimating in Agile uses techniques designed to avoid trying to estimate specific hours or workload. The main aim of Agile estimation is to focus on consistency instead of absolute accuracy. Instead of asking developers, “How long will this take?” they should be asked, “How big is this?” so that different stories can be compared against each other by relative size. Different organizations use various methods to indicate the relative size of a story, such as Planning Poker, story points (using the Fibonacci sequence), or T-shirt sizes (S, M, L).
As with other aspects of Agile, estimation is progressively elaborated, meaning you only estimate what is necessary at a certain time in the development cycle. This approach makes Agile estimating relatively quick and collaborative within a team. By repeatedly estimating and then reviewing the actual effort after work is complete, teams should become quite accurate in estimating new stories after a few iterations.
Wide Band Delphi
Wide-Band Delphi Estimating is derived from the original Delphi method, which was developed in the 1950s. It is called “wide-band” because, compared to the original method, it involves greater interaction and communication among the participants. The core benefit of the Wide-Band approach is that it retains the anonymity of the individual estimates to prevent groupthink, while still incorporating a structured discussion to benefit from the collective knowledge and expertise of the entire team.
The estimating process works as follows: The Product Owner gathers the team, presents the story (or feature to be estimated), and gives the team an opportunity to ask questions. Team members are then given individual forms where they anonymously fill in their effort estimation. If the estimates vary significantly, the group discusses the story again, focusing on any issues or perspectives that may have been overlooked and that led to the different estimates. This anonymous estimating and group discussion is repeated for as long as is appropriate to achieve convergence or until the discussion no longer yields new insights.
>> More Info on Wide Band Delphi by Project Management
T-shirt Sizing
T-shirt sizing is a relative sizing technique where a story is assigned a value of extra-small, small, medium, large, and extra-large.
>> More Info on T-Shirt Sizing by Asana
Planning Poker
Planning Poker is a technique used to estimate stories, where each person receives a deck of cards like the adjacent picture, each showing a story point value. The product owner presents the story, and the team may ask questions. Then, everyone simultaneously reveals a card indicating their estimate. If estimates differ, the team discusses and attempts another round. If consensus isn’t reached in the second round, the highest value is assigned to the story.
>> More Info on Planning Poker by PlanningPoker.com
Story Points
Story Points assign a numeric value to a story, typically using a sequence like Fibonacci—0, 1, 2, 3, 5, 8, 13, 21, 34—to discourage linking estimates directly to hours.
>> More Info on Story Points by Atlassian
Affinity Estimating
Affinity estimating is a technique where each story is placed on a table, and team members take turns either adding a card to the sequence or adjusting an existing one. After several rounds, when no one wishes to make further changes, the sequence should reflect the stories from easiest to hardest. The stories are then grouped by similar size, and a story point value is assigned to each group.
>> More Info on Affinity Estimating by Grey Campus
Ideal Time
Relative estimating using “ideal time” conveys how long a story would take if there were no interruptions.
>> More Info on Ideal Time by Project Management
Agile Estimating and Planning, a book by Agile Alliance co-founder Mike Cohn, explores the philosophy behind agile estimating and planning, offering practical guidance through real-world examples and case studies.
Customer Valued Prioritization
This involves keeping the product backlog prioritized to deliver maximum customer value. As new items are added, they’re compared to existing ones based on business value, ensuring the team selects top-priority items for the next iteration. This process continues throughout the project.
>> More information on Customer Valued Prioritisation from Scrum Study
MoSCoW
MoSCoW is derived from the first letters of the following:
- Must Have
- Should Have
- Could Have
- Would like to Have
It is highly effective and straightforward for getting the business to convey its priorities.
>> More information on MoSCoW from Product Plan
Simple Schemes
One of the simplest prioritization schemes is to label stories as Priority 1, 2, or 3—or alternatively, as High, Medium, or Low. While this method is easy to implement and understand, it can quickly lose its effectiveness if too many items are classified as high priority. To maintain its usefulness, it’s essential to establish clear and consistent criteria that define what qualifies as Priority 1, 2, or 3.
>> More information on Simple Schemes from Simple Learn
Monopoly Money
The Monopoly Money technique provides stakeholders with a fixed budget, equal to the project’s budget, in “monopoly money” to distribute among project features. This method is most effective when prioritizing a subset of features because, when applied to the entire backlog, stakeholders might inadvertently omit essential but less visible tasks like documentation.
>> More information on Monopoly Money
100-Point Method
Developed by Dean Leffingwell and Don Widrig for use cases, the 100-Point Method involves giving stakeholders 100 points to allocate across features. Stakeholders have the flexibility to distribute points however they choose, even assigning all 100 points to a single feature if it represents their absolute highest priority.
>> More information 100-Point Method from the Modern Analyst
Kano Analysis
Kano Analysis is a technique that categorizes features based on their potential to bring customer satisfaction. It helps identify which features will have the greatest impact on customers. Features are sorted into four categories:
- Indifferent: Features that bring neither satisfaction nor dissatisfaction.
- Delighters/Exciters: Unexpected features that greatly please customers.
- Satisfiers: Features whose presence increases satisfaction and whose absence causes dissatisfaction (Performance features).
- Dissatisfiers: Basic features customers expect, whose absence causes strong dissatisfaction (Must-be features).
>> More information on Kano Analysis by Tyner Blain
Dot Voting or Multi-Voting
In Dot Voting (or Multi-Voting), each stakeholder receives a predetermined number of votes or “dots” to distribute among features. A helpful guideline for determining the number of votes is 20% of the total items being prioritized. For instance, with 50 items, each person would receive 50×0.2=10 votes.
>> More information on Dot Voting from Dotmocracy
Requirements Reviews
Requirements reviews is another term for backlog grooming or refining. It’s crucial to remember that the customer is responsible for setting priorities and keeping the backlog up to date, ensuring the right value is pursued. Conversely, the delivery team is responsible for estimating the work, which allows the business to perform effective cost-benefit analysis for prioritization.
>> More information on Requirements Reviews from Bridging the Gap
Minimal Viable Product (MVP)
The Minimal Viable Product (MVP) must be defined to ensure that product releases deliver tangible business value. The MVP identifies the core features necessary to make the product functional and valuable enough for initial release. MVP is sometimes also referred to as a Minimum Marketable Feature (MMF), which describes a product that is complete enough to bring value but is clearly understood to be part of a larger, unfinished vision.
Relative Prioritisation/Ranking
Relative prioritization/ranking is a simple method to organize stakeholder priorities by assigning a numerical rank (e.g., 1, 2, 3, etc.) to features. This makes it straightforward to define an MVP (e.g., features 1-6). When new items are added, they must displace a current item or cause others to move down the priority list. This provides the team with a clear, ordered understanding of what work needs to be completed.
>> More information on Relative Prioritisation from Process Impact
Agile Communication Tools
Effective communication is vital in any project, and Agile is no exception. Agile projects typically communicate with three distinct groups, each requiring different information.
Stakeholder Communication
Stakeholders include senior management, third parties, and anyone else affected by the project. Agile communication for this group covers the same core areas as traditional projects—Status, Budget, and Problems/Issues—but focuses on results and performance rather than reporting on percentage complete. Reports to Stakeholders typically include:
- Burn-rate reports (comparing expected work vs. planned work).
- Reports on what has been delivered at the end of each iteration. This approach, combined with incremental builds and prioritized delivery, keeps stakeholders informed of current build progress.
>> More Info on Stakeholder Communication by Agile Modeling.com
33 x Agile Status Report Templates Word, Excel, Google
Business Owners/Sponsor Communication
The Business Owner is responsible for the Product Roadmap, which should be readily available to the team. They convey requirements through User Stories managed in the Product Backlog. Other Agile techniques used to convey requirements include Wireframes and Personas. Business owners participate in Iteration Reviews (often demos at the end of iterations) to inspect completed stories and ensure they meet their requirements.
>> Great article on girlsguidetopm.com on successful stakeholder management
Team Communication
The most important team tool is the Information Radiator (e.g., a physical or digital board) visible in the team area, displaying current progress via a burn-down chart, backlog, etc.
- Agile Retrospective: A crucial meeting after an iteration to review the process and discuss how it can be improved. A 2-hour retrospective for a 2-week iteration is a typical time-box.
- Daily Stand-Ups (DSUs): The team meets daily to explain what they did yesterday, what they plan to do today, and to highlight any blockers.
- Osmotic Communications: Agile promotes this, which is the constant interaction and mutual learning that happens when a co-located team is sitting together and overhears each other’s conversations.
>> 10 signs you should keep an eye for in new Agile Teams by AgileTimes.com
Communication techniques used in Agile are not exclusive to it—they can be applied to any project, regardless of the methodology.
Osmotic Communications
Osmotic Communication refers to information that flows in the background, allowing team members to pick up relevant details without active searching. It’s common in co-located teams where conversations are easily overheard. This style of passive information transfer is often more challenging for distributed teams.
>> More Info on Osmotic communication
Active Listening
Active listening is used to ensure both parties understand the topic of conversation. There are three ways to accomplish active listening by repeating exactly what the person says, paraphrasing by summarising what was discussed, and relaying it back, and reflecting on the conversation that just passed. All these techniques will result in a mutual understanding of a conversation.
The progression of our listening skills is internal listening (how will this affect me?) to focused listening (what are they really trying to say?) and then finally to global listening (what other clues do I notice to help me understand what they are saying?).
There are 3 Levels…..
Level 1: Internal Listening
We hear the words spoken but interpret through our own understanding, trying to put them into context, and how it affects you.
Level 2: Focused Listening
At this level, we let go of our own thoughts and embrace what the speaker is saying by putting ourselves in the mind of the speaker.
Level 3: Global Listening
This is building on level 2, but adding a higher level of awareness to pick up on subtle physical and environmental indicators.
>> More Info on Active Listening by Skills You Need
Social Media-Based
There are great social media tools readily available to teams to utilise, which enable IM between team members and can help organise social events. There is a great book called Strategic Integration of Social Media into Project Management Practice that goes into more detail about how a company should be using social media. What I like about the book is that you don’t have to buy the whole thing: you can just buy the chapters that are relevant, which makes it much more accessible.
>> More Info on Strategic Integration of Social Media into Project Management Practice
Brainstorming
Brainstorming is a group creativity technique where everyone gets to put forward ideas towards a specific problem. The term was popularised by Alex Faickney Osborn in the 1953 book Applied Imagination.
>> Applied Imagination Free Download
Two-Way Communication
Two-way communication is a form of transmission in which both parties involved transmit information.
>> More Info on Two-way Communication in Business
Feedback Methods
5 great ways of getting feedback from stakeholders would be:
- Surveys
- Feedback boxes
- Reach out directly
- User activity
- Usability Tests
Agile Metrics
Metrics are just as important in Agile as in Waterfall. They primarily provide a way to monitor and provide agile status reports on the project to stakeholders, but can also help the team improve their performance.
Velocity/Throughput/Productivity
There is no waterfall equivalent to velocity, as the team doesn’t work in iterations. The velocity is determined by gathering data during development and analyzing it to determine the expected throughput of the team per iteration. The velocity is the average amount of work completed in an iteration, measured in story points. The velocity will vary at the start while the team is getting used to estimating, but after a few iterations should start steadying and act as a baseline.
Once this baseline has been set, the team will be aware of how much work they should commit to in each iteration based on their expected velocity. This will result in the team being more productive and delivering exactly what was planned. If a velocity chart starts being erratic, it merits an investigation into the estimation and commitment process to determine if the team is over-committing, estimating that there is too much pressure on the team, etc.
>> More Info on How to Measure Velocity
Burn Time
Burn Rate is the budget equivalent of velocity. It tracks work completed against man-days (cost), which balances the scope-tracking function of velocity. The burn rate is the basis for the burn-down chart, which is key to tracking iteration progress.
Cycle Time
Cycle time is the total time working on an issue, from once the work begins to when it ends. This includes time if an issue is reopened, worked on, and completed again.
Lead Time
Lead Time is the total duration from identifying a requirement (e.g., writing a user story in Scrum) to its final completion (e.g., deployment to production). For instance, Kanban teams often use Lead Time instead of Velocity as their primary metric, focusing on reducing Lead Time to improve workflow efficiency.
Work In Progress (WIP)
Any software that has been started but not completed. This also includes stories that have been developed but not deployed to production can be considered “work in progress”.
- WIP consumes investment as it delivers no ROI until turned into an actual released product. It represents money spent with no return, which needs to be limited.
- WIP hides bottlenecks in processes that slow overall workflow.
- WIP represents a risk in potential unknown rework since there could still be changes for stories not yet accepted.
Defect Detection Rate
The Defect Detection Rate is the number of defects found per iteration. In theory, a team’s defect rate should correlate with its velocity: the more story points delivered, the more defects are likely to be reported, ideally at the same or a lower rate.
Defect Closure Rate
Defect closure rate is the number of defects closed in an iteration. It should equal a number of defects detected per iteration; if not, the defects are not being prioritized with a sprint and will end up moving along with the project.
>> More info on Defect Metrics in Agile by iSixSigma
EVM for Agile Projects
Earned Value Management (EVM) is a traditional project management technique adapted for Agile to track performance against plan for scope, time, and cost. Agile EVM uses Scrum artifacts as inputs and applies traditional EVM formulas. Estimates can use hours, story points, or any consistent numerical metric. The key metrics calculated are:
- Planned Value (PV): PV=Budget at Completion (BAC)×Story Points Planned
- Earned Value (EV): EV=Budget at Completion (BAC)×Story Points Completed
This analysis leads to two key performance indicators:
- Schedule Performance Index (SPI): SPI>1 is ahead of schedule; SPI<1 is behind schedule. A simple rule for interpretation is: “High is Good, Low is Bad.” (Though PMP exams typically focus on interpretation, not calculation.)
- Cost Performance Index (CPI): CPI>1 is under budget; CPI<1 is over budget.
>> Test your knowledge in EVM by taking our 200-question PMP practice exam
Earned Value Management Graphs
The Earned Value Management graph is a Double S-Curve graph, which has story points to the left, dollar value to the left, and dates on the x-axis. This enables us to track scope and cost on the same graph. The PMI-ACP usually doesn’t include many figures or graphs, but you might be asked to interpret an EVM or S-curve graph. You will not be asked to do any calculations.
- Once the CPI is calculated, if it is greater than 1, the project is under budget; if it is less than 1, the project is over budget; and if it is equal to 1, the project is on budget.
- Once the SPI is calculated, if it is greater than 1, the project is ahead of schedule; if it is less than 1, the project is behind schedule; and if it is equal to 1, the project is on schedule.
>> Great example of EVM by the PMI
Monitoring Agile Projects
An adaptive planning and monitoring approach acknowledges that planning is an ongoing process, and the following tools help to proactively update the plan. This is one of the biggest differences between traditional static planning to Agile adaptive planning.
Daily Stand-Ups (DSU)
The Daily Stand-Up (DSU) is a time-boxed 15-minute meeting held every morning by the Agile team. Each team member provides a high-level update by answering these three questions:
- What did I do since the last meeting?
- What do I plan on doing before the next meeting?
- Are there any impediments or blockers preventing me from moving forward?
Only team members should talk. The Product Owner and stakeholders may listen, and the Scrum Master/Team Leader is responsible for removing impediments. This “team-only-speaks” rule is often illustrated by the “pig and chicken” cartoon, where the pig (the team) is “committed” (bacon) while the chicken (the business) is only “involved” (eggs).
>> More info on DSU from Agile Pain Relief
Sprint Reviews
Sprint reviews are usually done by experts from outside the team. Their opinions are usually important and should be followed, or at least considered, by the team. At a certain level, reviews from outside the Agile team can impact the level of “pure” self-organization, since review brings in more people who can evaluate the product increment from different viewpoints. But will a review really break the agility and self-organization of the team? I believe not.
Reviews are needed for different reasons. If they’re not needed or aren’t beneficial to the organisation, of course, they should be reduced or removed from the life cycle. But let’s imagine here that they are needed and useful. We can take it as an internal requirement that should be weighed, just like the external customer requirement. If we can use self-organization to meet external customer requirements well, we can use it to meet such internal requirements as reviews.
>> More Info on How to Make Agile Reviews More Effective
Time-boxing
Time-boxing is limiting the time spent on an activity. A spike is a time-boxed activity to do research or investigate an “unknown”. The daily stand-up is time-boxed to 15 minutes. The retrospective is time-boxed to 2 hours.
WIP Limits
Work In Progress (WIP) Limits are used, especially on a Kanban board, to restrict the number of stories allowed in each workflow column. They are a strategy for detecting and preventing bottlenecks. Limits are agreed upon by the team and enforced by the facilitator. When a WIP limit is hit, the team stops starting new work and collaborates to clear the bottleneck. Little’s Law (a mathematical formula based on queueing theory) proves that work queue duration depends on its size, highlighting the importance of WIP Limits.
>> More info on setting WIP by the Agile Director
Variance Analysis
Variance Analysis is used to identify the difference between expected and actual performance. While some variation is expected (Common Causes – day-to-day differences), significant deviations are due to Special Causes (one-off events). Edward Deming noted the “classic mistake” of managers misinterpreting a common cause as a special cause, and vice versa.
>> More Info on Variance Analysis
Trend Analysis
Trend Analysis involves collecting and analyzing data to detect patterns that can predict the future trajectory of the data. This is a critical tool for detecting issues proactively before they occur. Trend metrics are leading metrics (insights into current/future performance), while metrics like budget consumed are lagging metrics (based on the past).
>> More Info on Trend Analysis
Burn Down
The burn-down demonstrates work remaining, the burn-up demonstrates work completed. As the burn-down chart is used to demonstrate the remaining work for a given period of time, it helps provide a quick update on whether the project is on track to hit its target. You can have a burndown chart for sprints and releases.
>> Really good article on Anti-patterns of Burndown Charts
Burn Up Charts
The burn-up chart shows how work has been completed and the total amount of work. One key difference between the charts is that the burn-up visibly demonstrates added/removed scope better than the burn-down charts.
>> More info on Burn Up Charts
Cumulative Flow Diagrams
A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of work items for a particular time interval. The horizontal x-axis in a CFD indicates time, and the vertical y-axis indicates cards (issues). Each coloured area of the chart equates to a workflow status.
>> More info on Cumulative Flow Diagrams
Backlog Grooming/Refinement
This is the process of ensuring the backlog is prioritized correctly. It is the Product Owner’s responsibility to refine the backlog, ordering stories from top to bottom so the team knows which item to select next. Backlog grooming should precede estimation sessions to ensure the right stories are selected for the upcoming iteration.
>> Cheatsheet on Backlog Refinement
Product-Feedback Loop
Product feedback is a core practice in Agile that every Agile methodology follows. Agile is all about delivering in frequent increments to gather feedback and adapt according to this feedback. The stakeholders are given demonstrations after iterations so they can review the product and provide feedback.
>> Great article on nature and gain from product feedback in Agile
Control Limits
Control limits are a technique where you can set upper and lower limits to determine acceptable variation. A useful method of control limits is setting an upper and lower limit of user stories completed per iteration.
>> More info on Control Limits in Agile
Pomodoro Technique
Pomodoro Technique is a lean concept based on individual time management, similar to plan-do-check-act, but scaled down for one person. The only tools you need are a kitchen timer, three sheets of paper, and a pencil.
>> The Lean Magazine did a great article on the Pomodoro technique in Scrum
Process Improvement
Process improvement is a very important part of Agile, and a truly Agile organisation or team understands that improvement is never complete. All Agile methodologies incorporate continuous improvement into their frameworks through regular reviews and by ensuring lessons are learned early. Capturing lessons learned early and applying improvements is critical — especially in projects with fast-changing environments, high levels of uncertainty, and risk. At the very least, there should be a review after each iteration to reflect on what went well, what didn’t, and what can be improved.
Kaizen
Kaizen comes from the Japanese term meaning “change for the better.” It is not defined by strict principles — rather, it is a mindset. Agile practitioners should adopt this mindset, always thinking about how to improve processes, team dynamics, and outcomes. Kaizen encourages making small, incremental changes and continuously iterating. If a small change proves successful, it should be made permanent — and then the team should continue iterating further.
A structured problem-solving process, particularly effective for Kaizen, is the Plan-Do-Check-Act (PDCA) cycle developed by Edward Deming. Agile has its own version of this cycle, often expressed as Plan-Develop-Evaluate-Learn, used during each iteration to support ongoing learning and improvement.
Retrospectives
After each release or iteration, the Scrum Master or Team Leader should hold a retrospective (also referred to as an intraspective). The goal of the retrospective is to improve methods and teamwork by reviewing the most recent iteration or release.
There are three core questions that should be answered in every retrospective:
- What is going well?
- What areas could be improved?
- What should we be doing differently?
Generally, a retrospective is time-boxed to 2 hours. It is based on brainstorming solutions, committing to actions, and then evaluating them in the next iteration. If a solution proves successful, it can be added to the standard process.
Retrospectives are highly effective because they take place during the development process, providing immediate feedback on team performance and process effectiveness. When used correctly, retrospectives can lead to:
- Improved productivity
- Improved capability
- Improved quality
- Improved capacity
Esther Derby and Diana Larsen: 5-Step Retrospective Process
Step 1: Set the Stage
Setting the stage is about establishing the tone for the meeting and getting the team engaged. Retrospectives are most effective when there is active participation and honest feedback. To encourage involvement, start with light activities such as:
- Check-In: A round-robin where each team member shares two sentences on what they want to get out of the retrospective.
- Focus On/Off: Participants share preferences on word pairs, e.g., Conversation vs. Argument, Understanding vs. Defending.
- ESVP (Explorers, Shoppers, Vacationers, Prisoners): Team members anonymously indicate their attitude towards the retrospective.
- Explorers: Eager to discover new ideas
- Shoppers: Looking for useful info, happy to leave with one idea
- Vacationers: Not interested in the retrospective, just glad to be away from work
- Prisoners: Feel forced to attend
- Working Agreements: Small groups create agreements that are combined into a master list for team conduct.
Step 2: Gather the Data
The next step is collecting feedback from the team on what happened during the iteration. The aim is to build a shared understanding of events. The team leader can use the following facilitation techniques to increase interaction:
- Timeline: The team creates a timeline of the iteration, noting milestones and issues.
- Triple Nickels: 5 groups rotate through 5 ideas, spending 5 minutes on each, 5 times.
- Colour-Coded Dots: Team members use sticky dots to indicate emotional highs and lows during the iteration.
- Mad, Sad, Glad: Participants use coloured cards to express emotional reactions.
- Locate Strengths: The team discusses what went well and why.
- Satisfaction Histogram: Visual representation of team satisfaction across iteration elements.
- Team Radar: Assessment of team performance against previous improvement goals.
- Like to Like: Recalling and comparing reactions to events during the iteration.
Step 3: Generate the Insights
Once the data is gathered, the team evaluates it to uncover root causes and patterns. Techniques include:
- Five Whys: In pairs, team members explore a problem by repeatedly asking “Why?” to get to the root cause.
- Fishbone Diagram (Ishikawa Diagram): Visual root cause analysis, where each “bone” represents a category and sub-causes are mapped underneath.
- Prioritise with Dots: Team members vote on what issues are most important using dot stickers.
- Identify Themes: Recurring patterns or topics are highlighted and discussed.
Step 4: Decide What to Do
With insights in hand, the team must now decide on actions. One effective technique is:
- Circle of Questions: One person states an issue, and the next suggests a solution. This continues around the team.
Any goals set must be SMART: Specific, Measurable, Attainable, Relevant, and Timely.
To organise actions, use an Action Wheel, where each item is categorised as:
- Keep / Drop / Add
- Start / More / Less
Step 5: Close the Retrospective
The final step is to formally close the retrospective. Four recommended closing activities are:
- Plus/Delta: What should we continue (+) and what should change (Δ)?
- Helped, Hindered, Hypothesis: Gather feedback on the retrospective itself.
- Return on Time Invested (ROTI): Team rates the value of the meeting on a scale from 1–5.
- Appreciations: Team members express gratitude to one another.
Esther Derby & Diana Larsen’s 5-Step Model
>> For more information, check out this PDF extract of Esther & Dianna book
Process Tailoring/Hybrid Models
Process tailoring is a continuous process in Agile. We are always striving to improve efficiency, reduce waste, and focus on what works versus what doesn’t. Every organization and project has different constraints and levels of flexibility, so the process must be modeled to suit these needs. Different companies implement different versions of Agile—some adhere strictly to one methodology, such as XP, while others use hybrids like Scrum and Kanban.
It is recommended that new teams begin with an “out-of-the-box” Agile implementation and make adjustments only after a few iterations. This helps the team understand why each process exists and recognize its value before deciding if it’s unsuitable. For example, in XP, there are multiple interdependent relationships (see diagram below). Relentless testing leads to refactoring, so the team must understand the balance before removing any tasks from the process.
Scrum is generally not open to major changes in its processes, but guidelines such as iteration length can be adjusted to fit an organization. Teams should raise process concerns during Agile retrospectives so they can be discussed openly, and small improvements can be implemented. Kanban, on the other hand, is an Agile methodology that welcomes change and can easily adapt to environmental requirements.
Value Stream Mapping
Value Stream Mapping originates from Lean manufacturing and is used to improve processes. The process is as follows:
- Identify Product: Identify the product, project, or process you want to improve.
- Create a Map of Current Processes: Map out the steps involved, how long each one takes, and the total process time.
- Review Map: When reviewing, you’ll identify two types of value in the process:
- Value-added time (working time)
- Non-value-added time (time wasted)
- Create New Process: After identifying non-value-added time, design a new process that removes waste and calculate the new process cycle efficiency (value added ÷ total cycle time).
- Create Roadmap for New Process: Develop a roadmap for implementing the proposed changes.
- Plan to Revisit: Once the process has been improved, revisit it to review the implemented changes. Compare the new total time against the original.
>> More information on Value Stream Mapping by Scaled Agile Framework
Pre-Mortem (Rule Setting, Failure Analysis)
A pre-mortem is a facilitated team exercise designed to identify potential failures in a project before they happen. This encourages the team to think long-term and visualize future challenges. The Product Owner must approve any mitigation or avoidance actions before they are added to the backlog. The steps for conducting a pre-mortem meeting are outlined below.
>> For more info on premortem by Fun Retrospectives
Imagine the Failure
- The team brainstorms possible issues that could arise.
- The facilitator may suggest scenarios.
Generate Reasons for the Failure
- Team members independently create lists of possible reasons for each potential failure.
- Example reasons include: funding removed, stakeholders not responding, or unclear requirements.
Consolidate the List
Each person reads one item from their list in turn while the facilitator records them on a whiteboard. This prevents long monologues and keeps everyone engaged.
The team then works together to prioritize the list based on perceived importance.
Revisit the Plan
- The Product Owner is provided with the list and has to approve the recommended actions. The Product Owner will only add what they feel is the top priority.
- Approved actions are turned into user stories and added to the backlog
Product Quality
Agile should always deliver high-quality products. To ensure this, we use the following tools:
Definition of Done (DoD)
The Definition of Done (DoD) is the set of criteria required to complete a story, feature, sprint, or release. There will be different DoDs at each level of an Agile project. The DoD has the following characteristics:
- Checklist of valuable activities: A simple list of required, value-adding activities that can be checked off.
- Primary reporting mechanism: Team members can confidently state that a story is complete if it meets its DoD.
- Not static: The DoD evolves over time as the team and organization mature.
In summary, the DoD is a clear checklist of value-added activities that ensure product quality is consistently maintained.
>> More information on DoD by Scrum Inc
Continuous Integration
Continuous Integration (CI) is a practice where developers frequently merge new code into the shared repository. It ensures quality is maintained throughout the project, even when multiple developers are working on different parts simultaneously. Each time someone checks in code, an automated regression test runs. This often happens several times a day.
Frequent automated testing ensures defects are identified soon after they’re introduced (for example, when the build turns red, meaning it fails). The team’s top priority is to get the build green again.
>> More information by Martin Fowler on continuous integration.
Exploratory Testing
Exploratory testing involves unscripted tests to quickly identify new types of software issues. While scripted tests verify functional components, exploratory testing focuses on uncovering extreme behaviors or edge cases. It’s usually performed by experienced testers skilled at finding unknown issues and unexpected behavior.
Great article on exploratory tests by Agilistry.com
Usability Tests
Usability testing evaluates how end users interact with a product. It helps answer questions like:
- Can users complete simple tasks?
- Are there repetitive actions required to complete a task?
- Is it unclear how to perform certain actions?
Usability tests are typically conducted in a controlled environment where the user’s screen is recorded as they perform various tasks.
>> More information on usability tests by Agile Modeling
Agile Risk Management Planning
A risk is an event that can occur and cause an unexpected outcome—positive or negative. In Agile, risks are generally discussed in terms of threats rather than opportunities.
Planning Risk Management
Project Risk Management, one of the nine PMBOK® knowledge areas, uses a risk register to document risks. Traditional project management follows this process:
- Risk Identification – Identifying risks to the project
- Risk Analysis – Analyzing identified risks
- Risk Prioritization – Determining high-priority risks
- Risk Management Planning – Planning risk responses
- Risk Resolution – Executing the plan
- Risk Monitoring – Continuously identifying and analyzing risks
Risks can be categorized as:
- Business: Related to business value
- Technical: Related to technology or skill sets
- Logistic: Related to schedule, funding, or staffing
- Other: Political, Environmental, Societal, Technological, Legal, or Economic (PESTLE)
More information on Risk Management
Schedule Risks
McConnell created a list of common schedule risks in software development, based on work by Boehm and Jones. He suggested that project risk can be reduced by directly addressing these issues:
- Feature Creep: Uncontrolled addition of requirements. The Product Owner must manage scope through change control.
- Gold Plating: Delivering features beyond requirements. The Product Owner should prevent unnecessary additions.
- Shortchanged Quality: Making short-term compromises to meet deadlines. In Agile, time, cost, and quality are fixed; scope should be adjusted instead.
- Overly Optimistic Schedules: Align requirements with team capacity and monitor velocity per iteration.
- Inadequate Design: Scrum lacks a dedicated design phase, increasing the risk of weak architecture.
- Silver Bullet Syndrome: Agile is not a guaranteed success factor; Agile projects can fail, too.
- Research-Oriented Development: Agile’s empirical nature helps minimize this risk.
- Weak Personnel: Agile does not mitigate this issue.
- Contractor Failure: Agile does not address this issue.
- Friction Between Developers and Customers: Agile does not inherently resolve this issue.
>> More information on Schedule Risks in Agile
Risk Register
A risk register is a log of all project risks and typically includes:
- Description of risk
- Date identified
- Probability, severity, and priority
- Owner, action, and status
The risk register should be updated during sprints and reviewed at each sprint planning session to prioritize upcoming risks.
More information on Risk Register
Risk-Adjusted Backlog
In a risk-adjusted backlog, the Product Owner prioritizes stories based on their associated risks. Stories with high probability and high impact are placed higher in the backlog, while low-probability, low-impact risks are deprioritized.
>> More Information on Risk Adjusted Backlog and much more from Edward
Risk Burn Down Graphs
A risk burndown chart visualizes the total risk over time and the rate at which risks are mitigated per iteration. It provides a high-level view of project risk trends and should ideally show a steady decline across iterations.
>> More information on Risk Burn Down Graphs from Mountain Goat Software
Risk-Based Spikes
A risk-based spike allows a team to explore or minimize a specific risk. If every possible approach fails, the project reaches a “fast failure” condition—where failing early costs less than failing later.
>> More information on risk-based Spikes from the Agile Dictionary
Architectural Spike
An architectural spike involves researching or investigating a specific area of the system, technology, or application to inform decisions.
>> More information on Architectural Spikes
Value-Based Prioritization
Agile focuses on delivering maximum business value in minimal time. Value-based prioritization drives this goal by leveraging Agile’s adaptive and iterative nature. Three main factors are considered:
- Business Value
- Risk or Uncertainty
- Dependencies
Financial Assessment Metrics
Value can be estimated using financial metrics such as ROI, NPV, and IRR. This applies to both Agile and traditional projects. Using financial metrics allows for unbiased prioritization across projects or stories. While these methods are more objective, they can still be manipulated through assumptions.
>> Great article by Stacey Barr on 7 Essential Project Performance Measures
Net Present Value (NPV)
Present Value (PV) calculates the worth of a future amount in today’s terms. Since future money is worth less due to interest and inflation, PV helps determine the real value of expected returns.
NPV extends this concept by calculating the net value of income minus cost over multiple periods. Add up individual PVs to find the total NPV.
Any project with a positive NPV is a good investment—always select the higher NPV when comparing options. Keep in mind that inflation and interest rate estimates can affect accuracy.
>> More information on NPV from Project Zone
Return on Investment (ROI)
Return on Investment (ROI) measures the ratio of benefits gained to money invested, expressed as a percentage. When prioritizing projects solely on ROI, always choose the one with the higher percentage, as it indicates a better return.
Internal Rate of Return (IRR)
IRR estimates the rate of return required for future revenues to equal current costs. It represents the discount rate, where revenues and costs break even.
Unlike NPV, IRR focuses on project duration and payback period rather than external interest or inflation rates. The higher the IRR, the more attractive the project.
>> More information on IRR in this article for Agile CFO’s
Agile Compliance
Stories prioritized based on compliance ensure the project adheres to internal or external rules, regulations, and policies. Compliance work can be approached in three ways:
- Doing compliance work as you go, aligning it with current stories.
- Doing compliance work after product development.
- Using a hybrid approach—performing some tasks during development and completing others afterward.
Conclusion: The Agile Toolbox
Ultimately, this compilation of Agile PM techniques is designed to be a durable resource for professional practice and academic preparation. Structured to align with the categories in the PMI-ACP Examination Content Outline, it offers a focused and practical study aid. The primary objective was to assemble a reliable Agile toolbox that practitioners can reference to confidently select the right tool—from prioritization methods like Kano Analysis to monitoring charts like the Cumulative Flow Diagram—in their daily activities. We hope this resource aids both current studies and future project success.
Suggested articles:
- 15 Game-Changing Agile Collaboration Team Techniques
- 6 Team Agile Communication Techniques & Digital Tools
- Crystal Agile Methodology: What Is It and Why It Matters?
Shane Drumm, holding certifications in PMP®, PMI-ACP®, CSM, and LPM, is the author behind numerous articles featured here. Hailing from County Cork, Ireland, his expertise lies in implementing Agile methodologies with geographically dispersed teams for software development projects. In his leisure, he dedicates time to web development and Ironman triathlon training. Find out more about Shane on shanedrumm.com and please reach out and connect with Shane on LinkedIn.