We have listed every Agile Tools and Techniques in project management to help traditional project managers with Agile projects. Just understanding the terminology is a big help to new project managers so they know what to expect when working with Agile teams.
- Wide Band Delphi
- T-shirt Sizing
- Planning Poker
- Story Points
- Affinity Estimating
- Ideal Time
- Customer Valued Prioritization
- Simple Schemes
- Monopoly Money
- 100-Point Method
- Kano Analysis
- Dot Voting or Multi-Voting
- Requirements Reviews
- Minimal Viable Product (MVP)
- Relative Prioritisation/Ranking
- Daily Stand-Ups (DSU)
- Sprint Reviews
- Burn Down
- Burn Up Charts
- Cumulative Flow Diagrams
- Backlog Grooming/Refinement
- Value Stream Mapping
- Pre-Mortem (Rule Setting, Failure Analysis)
- Definition of Done (DoD)
- Continuous Integration
- Exploratory Testing
- Usability Tests
Agiel planning is also know as Progressive elaboration is the process of elaborating at 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 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.
The product roadmap is a plan that aligns short and long term business goals with development solutions. The product roadmap is usually managed by the Product Manager who represents the business. Even though you might consider Agile only for short-term the roadmap is the same for Waterfall and Agile. Once a roadmap is created it is shared with the entire product team.
>> 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 delivered within the release. The iteration planning then is 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 detail and 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 commit 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 backlog
- Select user stories for backlog
- Define acceptance criteria and write acceptance tests
- Break down user stories into tasks
- Estimate the tasks.
>> More Information Iteration Planning by Version One
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.
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 next is 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 on, 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
A Kanban board is a tool used to visualise the workflow that enables the team to optimise the flow of work. A typical Kanban board will use sticky notes and have at least 3 columns where the far left is the backlog, middle in progress and far right is the done column. It easily communicates the work status of tickets.
25 x Free Kanban Board Template Excel, Powerpoint, Google Sheets (pm-training.net)
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 also.
> More Info on Wireframes by Just in Mind
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), Stakeholders (Who).
>> More Info on Project Charters by Infoq
Personas are when a team uses a fictional character that has the same characteristics of the end user. This helps the help gather an understanding of the user’s approach and decision making.
>> More Info on Persona’s by AgileAlliance.com
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 model 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 are where the team can be taught on new practices or software.
>> More Info on Workshops by Elabor8
A learning cycle is a concept of how people learn from experience.
>> More Info on Learning Cycle by Scaled Agile Framework
There are a number of collaboration games that help group communication. The following collaboration games were gathered from Karen and Samantha eBook (link below).
>> Karen Greaves and Samantha Laing free eBook on Collaboration Games here.
Broken Skype: Communication Collaboration
Time: 20 minutes
Team Size: 8-50 people
How: Group can’t talk only use hand signals. Group stands in a row passing from back to front a simple hand sign to one another. Repeat but pass a complex sign. Next everyone forms a circle and passes a complex hand sign to the left and only one person goes at a time and can correct based on what they see.
Result: After exercise asks team which was the best form of communication.
Crazy Chat: Respect Listening
Time: 5 minutes
Team Size: 2-100 people
How: Group is paired and 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. Then switch.
Result: After asking the each individual what did it feel like to ignore someone and what did it feel like not to be listened to.
Listening Game: Listening Collaboration
Time: 5 minutes
Team Size: 6-20 people
How: 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 before they say anything, the round will progress slower but will get a lot further than the first round.
Result: After ask how people felt during the rounds. Ask if anyone didn’t contribute in round two and how them doing nothing contributed to the overall goal.
Movers & Shapers: Respect Collaboration
Time: 10 minutes
Team Size: 10-100 people
How: Group is told they are to pretend to be a victim and need silently seek out 2 other people, an attacker, and shield. They must position themselves between the shield and attacker. They should do this for 2-3 minutes. Next, they are told to pretend to be a shield and need to silently seek out an attacker and victim and position themselves between them. They should do this for 2-3 minutes. Finally, they are told to pretend to be an equilateral triangle and to keep moving till it’s perfect. They should do this for 2-3 minutes.
Result: Ask what differences they saw between each round. First round when they are a victim they should end up moving further and further apart. Round two when they are a shield people should end up converging. Round three when they are equal they should come to equilibrium very quickly.
Human Knot: Self-Organization
Time: 15 minutes
Team Size: 8-100 people
How: Group forms two rows and there is one designated manager. First, the row should join left hand with back rows right hand. Then use spare hand to join with the neighbor person and at the end of the rows to the person in front of them, creating a human knot. The manager is to instruct the team how to untangle themselves and they can only follow their instructions.
Result: Usually the group succeed in a very short period of time and form a circle of joined hands.
Columbian Hypnotist: Respect Collaboration
Time: 5 minutes
Team Size: 2-100 people
How: Group is paired together and one is chosen to go first. They stand across from each other and the chosen one will move and the second person is to copy for 30 seconds. Then switch roles for another 30 seconds. Finally, ask to instruct instead of copying one another.
Result: Ask team after which they preferred and how they felt. Helps team members build up trust and starting moving.
Non-Musical Chairs: Self-Organization Trust
Time: 10 minutes
Team Size: 5-100 people
How: 1 person is to be the chairperson, there is to be 1 chair for every team member and one spare. The group is to prevent the chairperson from sitting on a chair without touching the chairperson, no moving the chairs and if you stand you must move and sit on a different chair. Give the team 1 minute to plan a strategy. Everyone is to move in a circle around the chairs. Tell 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 sitting on a chair for several minutes.
Result: Helps team understand the importance of inspecting and adapting.
Collaborative Origami: Communication Collaboration
Time: 20 minutes
Team Size: 5-50 people
How: Group forms pairs and are given a sheet and instructions to create an origami. Round 1 they sit back to back and try to complete origami with one instructing and one folding. Round 2 they sit face to face and try to complete origami, folder can’t see instructions, though. Round 3 they sit side by side both can see instructions and what is happening.
Result: Great for distributed games as it helps the team understand the limitations of different types of communications.
Magic Stick: Communication Collaboration
Time: 5 minutes
Team Size: 4-10 people1
How: Group stands in two rows and put a stick in between them on their index fingers only. Their aim is to lower the stick to the ground.
Result: Get the team to realize it is so much easier to achieve a goal when they work together.
Yes and: Collaboration
Time: 15 minutes
Team Size: 8-20 people
How: Each person has to start a phrase with “Yes, but”. You start the story and the next person is to continue with “Yes but”. After a few people, the story will no longer make sense. Next round get people to say “Yes and”. Final round repeat but people say “Because of that”.
Result: After team will have learned to build on others ideas rather than shutting them down.
Singing Clapping Numbers: Respect Collaboration
Time: 20 minutes
Team Size: 6-100 people
123 go: Communication
Time: 5 minutes
Team Size: 3-100 people
How: You tell the group you are going to count 123 and say “go” when you say go they should clap. Do it once quickly. Second-time pause and people will say “go” too early. Repeat 2-3 times.
Result: This demonstrates that people have hard wired responses, instead people should take their time and think about their responses.
Agile Estimating Tools
Estimating in Agile uses the following techniques which avoid trying to estimate specific hours or workload. The main aim of Agile estimation is to focus on consistency instead of accuracy. Instead of asking developers “How long?” they should be asked “How big?” so stories can be compared against each other.
As you read above Agile is progressively elaborated so you only estimate what is needed at a certain time in the development cycle. This makes Agile estimating a relatively quickly and collaboratively by a team and should result after a few iterations the team estimating stories pretty accurately. Different organizations use different methods to indicate the relative size of a story:
Wide Band Delphi
Wide Band Estimating is derived from the Delphi method which was created in the 1950s. It is called wide-band as compared to the original it involves greater interaction and communication. How the process works is the product owner gathers the team and presents the story and gives the team an opportunity to ask a question. The team is given individual forms where they anonymously fill in an estimation. If estimations vary the group discusses the story again and any issues overlooked which lead to different estimates. The process is repeated for as long as appropriate.
How the process works is the product owner gathers the team and presents the story and gives the team an opportunity to ask a question. The team is given individual forms where they anonymously fill in an estimation. If estimations vary the group discusses the story again and any issues overlooked which lead to different estimates. The process is repeated for as long as appropriate.
>> More Info on Wide Band Delphi by Lean Software Engineering
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 Rallydev
Planning Poker is a technique used to estimate stories where each person is given deck cards similar to the adjacent picture where each card has a story point value on it. The story is presented by the product owner and the team get to ask any questions. Then simultaneously everyone shows a card representing what they think the estimate should be.
If there are differences they are discussed and then another round of estimating is attempted. After the second round if there is not a unanimous decision the highest value is given to the story.
>> More Info on Planning Poker by PlanningPoker.com
Story Points assigns a numeric value to a story. Story points should be assign in a sequence such as the Fibonacci 0,1,2,3,5,8,13,21,34 etc to avoid associating stories with hours.
>> More Info on Story Points by AgileFAQ
Affinity estimating is a technique where each story is placed on a table and one by one a team member is given an opportunity to place a card in line or adjusting a card in the line already. After a few rounds where nobody wants to update the line, the line should represent the stories from easiest to hardest. Next, the stories can be grouped to similar size and then finally a story point is assigned to each group.
>> More Info on Affinity Estimating by GettingAgile
Relative estimating using “ideal time” is intended to convey how long a story would take if they were no interruptions.
>> More Info on Ideal Time by AgileSherpa
Agile Estimating and Planning a great book by Agile Alliance co-founder Mike Cohn discusses the philosophy of agile estimating and planning and shows you exactly how to get the job done, with real-world examples and case studies.
Customer Valued Prioritization
This is simply keeping the product backlog prioritised based on delivering maximum value to the customer. As new items are added to the backlog they are compared to current items on the backlog in terms of business value so when the team planning on next iteration they choose items on top of the backlog. This is an on-going process throughout the project.
>> More information Customer Valued Prioritisation from Scrum Study
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 their priorities.
>> More information MoSCoW from All About Agile
On of the simplest schemes is to label stories Priority 1, 2, 3 or high, medium and low. This is a very straightforward method but loses its effectiveness when too many items are marked high priority. A good way to govern this is to have defined ground rules what determines a priority 1, 2, 3.
>> More information on Simple Schemes from Leading Answers
The stakeholders are provided monopoly money equal to the projects budgets and asked to distribute the budget amongst the project features. Monopoly money technique works best when prioritising features as if prioritising the entire backlog the stakeholders might omit documentation or other tasks they don’t see the immediate value in.
>> More information on Monopoly Money
The 100-Point method was developed by Dean Leffingwell and Don Widrig for use cases. The stakeholders are provided 100 points which they can distribute amongst features. They can distribute any way they want even put 100 on one feature if it is their one and only priority.
>> More information 100-Point Method from the Modern Analyst
This technique categorises features into 4 categories:
This will help convey the features that bring the most customer satisfaction. Please see below image for reference.
>> More information Kano Analysis by Tyner Blain
Dot Voting or Multi-Voting
Each stakeholder gets a predetermined number of votes/dots and which they distribute amongst features. A good rule of thumb for assigning votes is 20% of total items for example if 50 items would be 50 x 0.2 = 10 so each person would have 10 votes.
>> More information Dot Voting from Dotmocracy
This is another name for backlog grooming or refining the backlog. Always remember the customer is responsible for setting the priorities and making sure the backlog is up to date. The delivery team is responsible for estimating the work so the business can effectively prioritise the work based on cost-benefit analysis.
>> More information Requirements Reviews from Bridging the Gap
Minimal Viable Product (MVP)
When planning releases of a product the releases need to deliver value to the business. For this reason, the MVP needs to be defined identifying what features need to be included to make the product functional and then plan releases around the MVP. MVP is also called MMF minimum marketable feature which the product is complete enough it brings value but yet still small enough that it is clear that it is not complete.
Regardless of how the backlog is prioritised the end goal is to understand the stakeholder priorities of the features. With relative prioritisation, it simply organises features by number 1,23 etc. This makes it easier to define a minimum viable product by simply say 1-6 need to be done to create the MVP. When new items are added to the list late on in development they will need to replace a current item in the MVP list or move down the priority of the item from 5 to 6. This helps give the team a clear understanding of what needs to be done to complete the project.
>> More information on Relative Prioritisation from Process Impact
Agile Communication Tools
Effective communication is essential in any project and it is no different for Agile projects. In Agile there are three different groups you will need to communicate with. Each of these groups requires different information to keep their needs satisfied during any particular project.
Stakeholders include all senior management, 3rd parties and anyone else affected by a project. Communication in an Agile project focuses on the same three items, (Status, Budget, and Problems/Issues) as would be expected from a traditional project. The key difference is Agile communication is more results/performance based as opposed to reporting on percentage complete. Reports provided to Stakeholders would include:
- Reports on Burn-rate (Expected Work vs Planned Work)
- Reports on what has been delivered at end of each iteration
These are only required to report to Stakeholders as Agile uses incremental builds and prioritised delivery so Stakeholders are provided information on the current builds.>> More Info on Stakeholder Communication by Agile Modeling.com
33 x Agile Status Report Templates Word, Excel, Google (pm-training.net)
Business Owners/Sponsor Communication
The business owner is responsible for the Product Roadmap which would be made readily available through the project team space to ensure the team is aware of the overarching objective. The business owner creates their requirements through User Stories, which are managed through the Product Backlog. Other Agile communication techniques business owners use to convey requirements could be Wireframes and Persona.
Business owners are also involved in Iteration Reviews where they get to see the completed stories to ensure it meets their requirements. Iteration reviews can be done contentiously or through demos at end of iterations.
>> Great article on girlsguidetopm.com on successful stakeholder management
The most important tool the team uses is the information radiator which is usually visible in the team area. The information radiator will have details on current progress using burn down chart, backlog etc. The team will meet at daily meetings where they explain what they did yesterday and plan on doing today and highlight any blockers. The team will have a workspace which can be public or private. For effective communications, Agile promotes Osmotic Communications which is constant interaction so the team can learn together and be a team.
Finally, the team will meet after an iteration to review the process and discuss how it can be improved, this is called a agile retrospective. Typically if it a 2-week iteration the retrospective would be 2 hours long.
>> 10 signs you should keep an eye for in new Agile Teams by AgileTimes.com
There are no communication techniques that are specific to just Agile but can be used on any project no matter the methodology.
Osmotic communication is information flowing in the background where teams can pick and choose when to contribute. This type of communication is common in co-located teams where the team are sitting together and can overhear each other’s conversations. As distributed teams can’t overhear each other this type of communication isn’t yet possible.
>> More Info on Osmotic communication by Allistair Cockburn
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 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 Skils 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 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 is a form of transmission in which both parties involved transmit information.
>> More Info on Two-way Communication in Business
5 great way of getting feedback from stakeholders would be:
- Feedback boxes
- Reach out directly
- User activity
- Usability Tests
Metrics are just as important in Agile compared to Waterfall. They primarily provide a way to monitor and provide agile status reports on the project to stakeholders but also can help the team improve their performance.
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 throughout 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 are over committing, estimating, is there too much pressure on the team etc.
>> More Info on How to Measure Velocity by VersionOne
Burn rate is the budget equivalent to velocity. Burn rate tracks work completed to man days. This enables you to track cost as the velocity tracks scope. Burn rate is also the basis for the burndown chart which is explained in the next chart but is a key chart to tracking the iterations progress.
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.
>> More info on Cycle time by Full Stack Agile
Lead time is the time from identifying a requirement and its completion. For Scrum, lead time would be from when the user story is written to when it is in production. Teams using Kanban would use lead time instead of velocity as a metric to help improve their workflow. For instance instead of increasing velocity a team using Kanban would aim at reducing the lead time.
Work In Progress (WIP)
Any software that has been started but no 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 limit.
- 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.
>> More info by LeanKit on WIP
Defect Detection Rate
Defect rate is a number of defects detected per iteration. In theory, the defect rate should correlate with the iterations velocity under the presumption developers will produce the same amount of defects at the same or less rate. The more story points delivered the more defects should be reported.
>> Agile Defect Explained by AgileLeanKanban
Defect Closure Rate
Defect closure rate is the amount 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 a project.
>> More info on Defect Metrics in Agile by iSixSigma
EVM for Agile Projects
Earned Value Management is a well known traditional project management technique to determine a project’s performance and help forecast future performance. It tracks scope, time and cost against planned performance. Agile EVM is an adapted version of earned value management. Agile EVM uses Scrum artifacts as inputs and then uses the traditional EVM formulas to provide traditional EVM metrics. Estimates can be in hours, story points, team days or any metric that is consistent in sizing stories as long as it is a numerical value. To calculate you can start by gathering per story: Estimated Story Point, Completed Story Point, Actual Cost then add them up either by iteration or total to calculate Planned Value and Budget.
Planned Value (PV) = Budget at Completion (BAC) x Story Points Planned
Earned Value (EV) = Budget at Completion (BAC) x Story Points Completed
>> 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 CPI is calculated if it is over 1 it is under budget, under 1 it is over budget and equal to 1 is on the budget.
Once SPI is calculated if it is over 1 it is ahead of schedule, under 1 it is behind schedule and equal to 1 is on schedule.
*For remembering this I just think “High is Good, Low is Bad”
>> Great example of EVM by the PM Journal with EVM Graph
Monitoring Agile Projects
An adaptive planning and monitoring approach acknowledges that planning is an ongoing process and the following tools help to pro-actively update the plan. This is one of the biggest difference between traditional static planning to Agile adaptive planning.
Daily Stand-Ups (DSU)
The daily stand-up is a time-boxed 15-minute meeting held by the team Agile team every morning. Each team member will keep their update at a high level and should answer the following three questions:
- What they did since last time they talked.
- What they plan on doing before the next meeting.
- Are there are impediments or blockers preventing them from moving forward.
Only team members will talk not the product owner or any other stakeholders. The product owner can answer the team’s questions and the Scrum Master/Team Leader will be responsible for removing impediments. To further understand why only the team members only talk check out the below cartoon about the pig and chicken. In simple terms, if the pig and chicken open a breakfast restaurant together selling bacon and eggs, the pig (team) will have it all to lose and the chicken (business) will only be involved.
>> More info on DSU from Agile Pain Relief
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 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.
Work In Progress limits is used to limit the amount of stories allowed in each column on a Kanban board. WIP limits are a strategy for detecting preventing bottlenecks. The WIP limits are agreed by the team before a project starts and enforced by the team facilitator. When a WIP limit has been hit for a certain task the team stops and works together to clear the bottleneck. John Little created Little’s Law a mathematical formula based on queueing theory that can be used to analyse work queues on Cumulative Flow Diagram. The formula proves that the duration of work queue is dependent on its size which is why WIP Limits are so important.
>> More info on setting WIP by the Agile Director
Variance analysis is used to identify the difference between expected and actual performance. Variance measures how far apart things are and how much they vary. Some variance is expected but it should be within acceptable limits, even highly engineered processes take into account some degree of normal variation due to normal fluctuation. Edward Deeming defined two types of variation:
- Common Causes: These are issues that are day-to-day differences to doing work.
- Special Causes: These are are issues that cause greater variance by a one-off or special cause.
Deeming determined it is a classic mistake where managers misinterpret common cause for a special cause and vice a verse.
>> More Info on Variance Analysis
Trend analysis collects data and analyzes them to detect patterns that may predict the future trajectory of the data. It is a very important tool for detecting problems as it provides insights into issue’s before they occur. Trend metrics are leading metrics as they provide an insight into what is happening now or in the future. Lagging metrics are metrics such as budget consumed which are based on the past.
>> More Info on Trend Analysis
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 if 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 both charts is that the burn-up visibly demonstrates added/removed scope better than 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 by the Agile Sherpa
This is the process of making sure the backlog is prioritised. It is the Product Owners responsibility to ensure the backlog is refined correctly. The backlog stories are prioritised from the top down, so the team will know to choose the story on top of the backlog to work on next. Backlog grooming should be done before estimation sessions so the correct stories are estimated and selected for the next iteration.
>> Cheatsheet on Backlog Refinement
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 on product feedback in Agile
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 is 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 Pomodoro technique in Scrum
Process improvement is very important part of Agile and a truly Agile organisation/team will understand that process improvement is never complete. All Agile methodologies incorporate continuous improvement into their framework with reviews and ensuring lessons are learned early. Capturing lessons learned early and improving is critical especially projects quickly changing environment high degree of uncertainty and risk. At very least there should be a review after each iteration reviewing what went good and bad.
Kaizen comes from the Japanese for “change is for better”. There are no principles for Kaizen-it is a mindset that Agile practitioners should have to be always thinking on how to improve. Kaizen recommends making make small changes and constantly iterate. If the small changes work then make them permanent and iterate. A controlled problem-solving process which is particularly effective for Kaizen is the Plan-Do-Check-Act (PDCA) by Edward Deming. Agile have their own version of which is Plan-Develop-Evaluate-Learn by Agile (iteration).
>> More info on Kaizen by Getting Agile
After each release/iteration, the Scrum Master/Team Leader should hold a retrospective which can also be called an intraspective. The aim of the retrospective is to improve methods and teamwork by reviewing the past iteration/release. There are 3 core questions that should be answered in every retrospective:
- What is going well
- What areas could be improved
- What should be we be doing differently
Generally, a retrospective is time-boxed to 2 hours and is based on brainstorming solutions and commit to a solution and discuss again, if success adds to the process. Retrospectives can be highly effective as they happen during the development process providing immediate feedback on how the process is performing. If used correctly retrospectives can result in:
- Improved productivity
- Improved capability
- Improved quality
- Improved capacity
Esther Derby and Diana Larsen defined a 5 step process for holding retrospectives.
Step 1: Set the Stage
Setting the stage is all about setting the tone of the meeting and getting the team on board. Retrospectives work best when there is a lot of engagement and genuine feedback from the team. It is recommended to get people talking early by introducing themselves and their role but if the team members don’t change very often this might be seen as overkill. Next, the Scrum Master/Team Leader sets an agenda and rules for the meeting. To increase comfort level of team members to participate in the meeting the team can play the following games
Check In: Round robin where people give 2 sentences on what they want to get out of retro
Focus On/Off: Get people give their opinion on each pair of words ie. Conversation vs Argument, Understanding vs Defending
ESVP: The team anonymously identify their attitude towards retrospectives as one of the following:
- Explorers: eager to discover new ideas
- Shoppers: look for useful info and happy go home with 1 idea
- Vacationers: not interested in retro but happy to be away from work
- Prisoners: feel like being forced to attend
The total scores are kept and the individual votes disposed of. Then the team is asked how they feel about the results.
Working Agreements: small groups and create agreements, create master list
Step 2: Gather the Data
Next step is gathering feedback from team members on what happened during iteration. The goal is to determine a common vision of the iteration. The team leader can use the following team based facilitation techniques to get more interaction between team members:
- Timeline: The team creates a timeline of the iteration highlighting any milestones, issues occurred during the iteration.
- Triple Nickles: 5 groups are given 5 minutes on 5 ideas 5 times
- Colour Coded Dots: Team uses sticky dots to show emotions where emotions ran high/low during the iteration.
- Mad, Sad, Glad: Team uses coloured cards to describe emotional reactions during iteration
- Locate Strengths: Team discusses what went well during the iteration.
- Satisfaction Histogram: Team uses a histogram to demonstrate satisfaction for particular parts of the iteration.
- Team Radar: Team assesses performance against previous process improvement goals
- Like to Like: Team recalls experiences during iteration and compares reactions to events.
Step 3: Generate the Insights
Once the data on the iteration has been gathered it needs to be evaluated. The data can be evaluated using the following brainstorming techniques:
- Five Why: The team works in pairs where they look at an issue and try find a solution by asking “Why?” numerous times to any reason for the issue helping determine the root cause.
- Fishbone Diagram Analysis: Also called Ishikawa diagram it is a technique used to identify root cause demonstrated in the diagram to the left. The team draws out the diagram, each branch is one area and then within that branch are possible reasons for that branch. The diagram should have all possible causes and which area the issue came from.
- Prioritise with Dots: Team uses dots to vote on what they feel is important to them.
- Identify Themes: The team identifies recurring patterns in the data gathered.
Step 4: Decide What To Do
After the data has been evaluated and the team have the insights into the issues they must decide how to rectify them. The technique called “circle of questions” can be used to give individuals opportunities to provide solutions where a person picks an issue and the next person proposes a solution. It is very important that any goals created to rectify an issue are SMART goals (Specific, Measurable, Attainable, Relevant & Timely). This will help ensure the goals are achievable within the next iteration and can be reviewed after. To sort the issues the team can use an action wheel where each item is categorised simply by choosing Keep/Drop/Add or Start/More/Less.
Step 5: Close the Retrospective
The final stage of the retrospective is formally closing it. There 4 tasks identified to close the retrospective is:
- Plus/Delta: What they want to do more of and want to change
- Helped, Hindered, Hypothesis: Feedback on retrospective itself giving everyone an opportunity to give their feedback.
- Return on invested Time: Team grade meeting 1-5
- Appreciations: The team members express appreciation to each other.
Esther Derby & Diana Larsen Going Through 5 Stages
>> For more information check out this PDF extract of Esther & Dianna book
Process Tailoring/Hybrid Models
Process tailoring is a continuous process when it comes to Agile, we are always trying to improve and make it more efficient reducing waste and focusing on what works versus what doesn’t. Every organisation and project will have different constraints and flexibility so the process will need to be modelled to suit these needs. Different companies implement different versions of Agile, some strict to one methodology such as XP others hybrids of different methodologies such as Scrum and Kanban.
It is recommended though new teams should use “out-of-the-box” agile implementation and then change after a few iterations. The reason this is recommended so the team knows why the certain process is there, need to recognise the value in the process before deciding not suitable. For example, in XP there are multiple relationships dependent on each other (See diagram below). As you can see relentless testing leads onto refactoring so the team needs to understand the counter balance before making the decision to remove a task from the process.
Scrum is also not open to change in its processes but guidelines like iteration length can be changed to suit an organisation. The team should be raising concerns with the process in the agile retrospectives so it can be discussed openly and small changes could be implemented to improve the process. Kanban is an Agile methodology that is friendly to change and can adapt to the environments requirements.
Value Stream Mapping
Value stream mapping is originally a Lean manufacturing technique to improve processes. The process is as follows:
- Identify Product: First thing is to identify the product, project, process you want to improve
- Create Map of Current Processes: Map out the process and how long each process takes and the total process time.
- Review Map: When reviewing you will identify two types of value during a process:
- Value-added time (Working time)
- Non-value added time (Time wasted)
- Create New Process: After reviewing the process and identifying non-value added time the new process will remove these calculating the new process cycle efficiency b value added/total cycle time
- Create Roadmap for New Process: Create a roadmap on how to implement the proposed changes to the current process.
- Plan to Revisit: After the process has been improved it should be revisited to review the implemented changes and the new improved process. Review by the new total time versus the original.
>> More information on Value Stream Mapping by Scaled Agile Framework
Pre-Mortem (Rule Setting, Failure Analysis)
The premortem is a facilitated team exercise that aims to identify the possible failures on a project before they happen. This helps the team to think long-term and visualise future change’s they might experience. The Product Owner needs to approve any mitigation or avoidance actions before they can be added to the backlog. The steps to conducting a post-mortem meeting are below.
>> For more info on premortem by Fun Retrospectives
Imagine the Failure
- The team brainstorms possible issues that could arise.
- The facilitator can suggest scenarios.
Generate Reasons for the Failure
- The team members work independently to create a list of possible reasons for each failure.
- Example reasons would be funding removed, stakeholders not answering questioning.
Consolidate the list
- Each person reads out one item from their list in turns and writes on the whiteboard, which prevents long monologues and encourages engagement.
- The team works together to prioritise the list based on their opinions.
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 backlog
Agile should always deliver high-quality products and to ensure this we use the following tools.
>> Free PDF by Crosby, P. B. (n.d.). Quality is Free – if you understand it. Philip Crosby Associates II, Inc.
Definition of Done (DoD)
The definition of done is simply the criteria required to complete a story, feature, sprint or release. There will be different DoD at every level of an agile project. The DoD has the following characteristics:
- Check-list of valuable activities: Simple list of required activities that add value to the product which can be checked
- Primary reporting mechanism for team members: A team member can confidently say a story is complete if it meets its DoD
- Not a static definition: DoD changes over time as team and organisation changes
In summary, the DoD is a definite checklist of necessary value added activities that ensure the quality of the product is maintained.
>> More information on DoD by Scrum Inc
Continuous Integration is a practice used by software developers to frequently incorporate new code into their projects code repository. It is all about maintaining quality all the time, throughout the project regardless having multiple developers working on different parts of the code at the same time. It involves automatically integrating and running a regression test every time somebody does a check in. This is likely to happen several times a day. Running an automated regression test frequently means defects are highlighted soon after they are introduced (i.e. when the build goes Red, i.e. fails). The team’s top priority is to get the build Green again.
>> More information by Martin Fowler on continuous integration.
Exploratory tests use un-scripted tests to quickly identifying new types of problems with the software. Scripted tests would be used to test functional components of a system. Exploratory tests are used to find extreme behaviour or edge cases. Exploratory tests would usually be performed by an experienced tester who are used to finding unknown issues and unexpected behaviour.
>> Great article on exploratory tests by Agilistry.com
Usability tests are used to test how the end user interacts with the product. it will uncover answers to questions like:
- Are they able to complete simple tasks?
- Are there repetitive actions to complete a task?
- Is it not clear how to action something?
Usability tests would be performed in a controlled environment where an end user screen would be recorded as they are asked to perform various tasks.
>> More information on usability tests by Agile Modeling
Agile Risk Management Planning
A risk is something that can occur and cause unexpected outcome which can be positive or negative. In general, when risks are being discussed in relation to Agile it will be in regards to threats, not opportunities.
Planning Risk Management
Project Risk Management is one of the 9 management knowledge areas in the PMBOK® which uses a risk register to document risks. The process in traditional project management would be the following:
- Risk Identification (Identifying risks to a project)
- Risk Analysis (Analysing identified risks)
- Risk Prioritisation (Identify high priority risks)
- Risk Management Planning (Plan risk responses)
- Risk Resolution (Execute plan)
- Risk Monitoring (Continuous risk identification and analysis)
Risk can be categorised into the following:
- Business (Related to business value)
- Technical (About technology use and/or skill sets)
- Logistic (Related to schedule, funding, staffing, etc.)
- Others (Political, Environmental, Societal, Technological, Legal or Economic (PESTLE))
>> More information on Risk Management
McConnell created a list of common schedule risks in software development based on work originally done by Boehm and Jones. He proposed that the projects risk can be reduced by directly addressing these common risks:
- Feature Creep (Feature creep is uncontrolled addition of requirements to the scope of a project. Having a Product Owner to protect the project’s scope by using Change Management)
- Gold Plating (Gold plating is when a feature is delivered excelling requirements. A Product Owner should prevent this as they should know what the team is working on).
- Shortchanged Quality (This is referring to making short-term changes to meet a target or deadline. Agile makes the trade off for scope, cost, time and quality explicit. Time, cost and quality are fixed in Agile and Scope is the only variable so features should be dropped instead of quality to meet a deadline)
- Overly Optimistic Schedules (Requirements should be mapped to capacity based teams delivery of story points per iteration. The team’s velocity should be constantly monitored and adjusted based on data).
- Inadequate Design (Scrum does not cover the full project lifecycle and works best for implementing software as there is no single design phase prior to the work starting. This can lead to a risk of inadequate design).
- Silver Bullet Syndrome (Just because a project is using Agile does not mean it is destined for success, Agile projects fail too)
- Research-oriented Development (The empirical nature of Agile means the risk of running a research orientated project is reduced)
- Weak Personnel (Agile doesn’t affect this issue)
- Contractor Failure (Agile doesn’t affect this issue)
- Friction Between Developers and Customers (Agile doesn’t affect this issue)
>> More information on Schedule Risks in Agile
A risk register is a collection of all risks in a project and would include the following fields:
- Description of risk, Date Identified
- Probability, Severity, Priority
- Owner, Action, Status
The risk register should be updated during sprints and reviewed at each sprint planning session to ensure any risks need to be prioritised for next sprint.
>> More Information on Risk Register from Agile Gov Leaders
This is when the Product Owner prioritises stories on a backlog based on the risk associated with the story. If a risk has high probability and impact on the project it would be prioritised high on the backlog but if the risk had a minimum impact and probability of happening it will be lower in the backlog.
>> More Information on Risk Adjusted Backlog and much more from Edward
Risk Burn Down Graphs
A risk burndown chart demonstrates the total amount of risk associated with the project and risks eliminated per iteration. It provides a high-level overview of how many risks present in the project at a given time. It would be expected to linearly decrease over iterations.
>> More information on Risk Burn Down Graphs from Mountain Goat Software
A risk-based spike is used to allow the team to eliminate or minimise a risk. If a risk-based spike fails for every possible approach the project reaches a condition as “fast failure” where the cost of failure is away less than failing later.
>> More information on risk-based Spikes from the Agile Dictionary
An architectural spike is when research/investigation needs to be conducted on an area of the system, technology or application.
>> More information on Architectural Spikes
Agile is all about delivering the maximum business value in a minimum time span. Value based prioritisation is a core principle that drives structure and functionality of Agile frameworks. Value based prioritisation benefits from Agile’s adaptive and iterative approach. Three factors are considered when prioritising:
- Business Value
- Risk or Uncertainty
Financial Assessment Metrics
Value is often estimated using financial metrics such as ROI, NPV and IRR. This is the same for Agile and traditional projects. Using financial metrics helps prioritise projects or stories based on a common metric which removes bias. In theory using financial metrics should be more accurate than other selection methods but they can be manipulated to sway the outcome.
>> Great article by Stacey Barr on 7 Essential Project Performance Measures
Net Present Value (NPV)
Firstly you should understand that Present Value is a method of calculating the value of a future amount in today’s terms. This needs to be calculated as it is a basic rule of finance that money expected to receive in the future is less valuable than the invested money. This is especially true when the investment money needs to be borrowed which needs to be paid back with interest, this is why you need to calculate present value using an assumed interest and inflation rate
A value of future cash flow in today’s dollars calculated in discounted cash flow.
Where…..FV = Future ValueI = Rate of Return
We extend this concept to find the present value of return for a project. Net Present Value is the present value (income – cost) over series of time periods. Add up individual PV to calculate NPV
Where….FV = Future ValueI = Rate of Returnn = Year
Any project with a positive NPV is a good investment as you will make the investment back, always select the higher NPV when comparing projects. NPV is very useful for comparing projects starting at different time frames. One thing to take into consideration when calculating NPV the inflation and interest rates will be estimated which could turn out to be incorrect.
>> More information on NPV from Project Zone
Return on Investment (ROI)
Return on investment is the ratio of benefits from an investment of the money invested expressed as a percentage. When prioritising based solely on ROI always choose the project story with higher ROI as the higher means the better return.
>> More information on ROI from Software Value
Internal Rate of Return (IRR)
IRR is how companies deal with estimating inflation and interest rates. Originally from the financial term “discount rate” it means “the interest rate you need to earn a given amount of money today to end up with a given amount of money in the future”. ie. IRR = discount rate at which revenues and costs are equal.
Unlike NPV instead of using estimates on future interest and inflation rates to calculate the value of a project you use estimates of project duration and payback period to calculate the interest rate. Always choose the higher value as the higher the rate the higher the value.
>> More information on IRR in this article for Agile CFO’s
Stories that are prioritised based on compliance are related to making the project comply with internal/external rules, regulations and policies. There are three options to dealing with these stories…
- Doing the compliance work “as you go” which keeps it in line with the stories being worked on at the time
- Doing the compliance work after the product is developed
- A hybrid solution where you do some compliance tasks during the product development and complete them after
Download, Save, Like, Share
Thanks for reading my list of Agile PM Techniques hope it helped you discover some new techniques you can use in your day to day Agile activities. You can download a PDF version by clicking the above image. Please feel free to share the document with colleagues or anyone studying for the PMI-ACP® exam. If you don’t have time to read the list right now you can download the pdf and read it later just provide your details at the bottom of the post.
Interested in learning more about Agile?
Try our 120 question PMI-ACP Practice Test to see if you can pass it by getting over 70%
fyi. This is not an exhaustive list of Agile Techniques. The list was written up while I was studying for the PMI-ACP® exam. For this reason, the format corresponds to the categorization in the PMI-ACP® Examination Content Outline. You can find more information about PMI-ACP® here. Hope this helps your studies and can be an Agile Toolbox you can reference later when looking for an appropriate tool or technique.