PMI-ACP: 100 Agile Software Tools

9/9/19
1
PMI-ACP
100 Agile Tools
MSc. PMP. Nguyen Thanh Phuoc
phuocnt@gmail.com
1. Agile Analysis & Design
(Domain Value Driven Delivery)

9/9/19
2
Product Roadmap
• 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
3
Story Mapping
4
• 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

9/9/19
3
User Stories
5
• A user story is a tool used in Agile development to describe
software requirement. 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>
User Stories (cont.)
6
• 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

9/9/19
4
Wire-frames
7
• 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
Chartering
8
• Project Charters are used as the project’s vision, mission and
success criteria
– Vision: The vision defines the “Why” of the project. This is the higher purpose, or
the reason for the project’s existence.
– Mission: This is the “What” of the project and it states what will be done in the
project to achieve its higher purpose.
– Success Criteria: The success criteria are management tests that describe effects
outside of the solution itself
• Generally, a project charter will include
– Business value (Why),
– High-level requirements (How),
– Stakeholders (Who)

9/9/19
5
Persona’s
9
• 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
Agile Modelling
10
• 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

9/9/19
6
Workshops
11
• Workshops are where the team can be taught on new practices or
software
Learning Cycle
12
• A learning cycle is a concept of how people learn from experience

9/9/19
7
Collection of Collaboration Games
13
• There are a number of collaboration games that help group
communication
• The following collaboration games were gathered from Karen and
Samantha eBook
– Broken Skype - Magic Stick
– Collaborative Origami - Movers & Shapers
– Crazy Chat - Yes and
– Listening Game - Human Knot
– Singing Clapping Numbers - 123 go
– Columbian Hypnotist - Non-Musical Chairs
Collaboration Games > Broken Skype
• Purpose: 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.
14

9/9/19
8
Collaboration Games > Collaborative Origami
• 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.
15
Collaboration Games > Crazy Chat
• Purpose: Respect Listening
• Time: 5 minutes
• 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.
16

9/9/19
9
Collaboration Games > Listening Game
• Purpose: Listening Collaboration
• Time: 5 minutes
• 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.
17
Collaboration Games > Magic Stick
• Time: 5 minutes
• 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.
18

9/9/19
10
Collaboration Games > Movers & Shapers
• Purpose: Respect Collaboration
• 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
19
Collaboration Games > Yes and
• Purpose: Collaboration
• 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.
20

9/9/19
11
Collaboration Games > Yes and
• Purpose: Collaboration
• 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.
21
Collaboration Games > Human Knot
• Purpose: Self-Organization
• 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. 22

9/9/19
12
Collaboration Games > 123 go
• Purpose: Communication
• Time: 5 minutes
• 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.
23
2. Agile Estimating
(Domain Adaptive Planning)
24

9/9/19
13
Wide Band Delphi
25
• 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.
T-shirt Sizing
26
• T-shirt sizing is a relative sizing technique where a story is
assigned a value of extra-small, small, medium, large and extra-
large.

9/9/19
14
Planning Poker
27
• 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.
Story Points
28
• 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.

9/9/19
15
Affinity Estimating
29
• 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.
Ideal Time
30
• Relative estimating using “ideal time” is intended to convey how
long a story would take if they were no interruptions.
• 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.

9/9/19
16
3. Communications
(Domain: Stakeholder Engagement)
31
Stakeholder Communication
32
• 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 prioritized delivery so Stakeholders are provided information on
the current builds.

9/9/19
17
Business Owners/Sponsor Communication
33
• 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.
Team Communication
34
• 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 retrospective.
• Typically if it a 2-week iteration the retrospective would be 2 hours long.

9/9/19
18
Osmotic Communications
35
• 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.
Active Listening
36
• 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 summarizing what was discussed and
relaying it back and reflecting on the conversation that just passed.
• 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.

9/9/19
19
Social Media Based
37
• There are great social media tools readily available to teams to
utilize which enable IM between team members and can help
organize 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.
Brainstorming
38
• Brainstorming is a group creativity technique where
everyone gets to put forward ideas towards a specific
problem. The term was popularized by Alex Faickney
Osborn in the 1953 book Applied Imagination

9/9/19
20
Two-Way Communication
39
• Two-way communication is a form of transmission in
which both parties involved transmit information
Feedback Methods
40
• 5 great way of getting feedback from stakeholders
would be:
– Surveys
– Feedback boxes
– Reach out directly
– User activity
– Usability Tests

9/9/19
21
4. Interpersonal Skills
(Domain: Stakeholder Engagement)
Emotional Intelligence
42
• Emotional intelligence the capacity to be aware of,
control, and express one’s emotions, and to handle
interpersonal relationships judiciously and
empathetically.
• There are 4 quadrants are illustrated in the aligning
diagram. For one to improve they first need to become
self-aware and then self-manage before they can start
helping others

9/9/19
22
Adaptive Leadership
43
• Agile adaptive leadership is key for an organization to effectively be Agile.
These three things are a responsive strategy, being and doing Agile. Yes, it is
one thing “doing” Agile in an organization but it is another “being” an Agile
organization.
– Responsiveness Strategy
– Doing Agile: Agile leaders use the following execution levels to help them
achieve business goals:
• Quality: Managing technical debt.
• Doing Less: Priorities features that bring the most value to a customer
• Engage/Inspire: Encourage and promote self-organizing teams.
– Being Agile: Core principles companies should adopt to be Agile would be
• Release Quickly - Incremental Delivery
• Deliver Value - Coach the Agile Mindset
Collaboration
44
• Collaboration is a joint effort of multiple individuals or
work groups to accomplish a task or project.
• Within an organization, collaboration typically involves
the ability of two or more people to view and
contribute to documents or other content over a
network

9/9/19
23
Negotiation
45
• Negotiating is all about achieving a win-win situation
where both parties. Negotiations may happen within
groups or individuals inside or outside an organization
Servant Leadership
46
• Firstly the word “leadership” is the science of leading a team and “servant
leadership” is the philosophy and practice of helping a team thrive and hit its
goals
• puts serving others — including employees, customers, and community — as
the number-one priority
• Key characteristics of a servant leader would include awareness, listening,
persuasion, empathy and coaching
• Typical Scrum Master tasks would include:
– Protector of the team Ensure they are all well informed and trained in Scrum
– Facilitates meetings and Scrum ceremonies
– Makes sure team doesn’t over commit
– Helps team reach goals

9/9/19
24
Conflict Resolution
47
• Conflicts can happen for a number of reasons such as:
– Schedule Priorities Resources
– Costing Personality
• Techniques to Manage Conflict:
– Confronting: Also called problem-solving it is where the problem is confronted not the
person, where the problem is dealt with head-on.
– Collaborating: When individuals or teams work with other individuals or teams to solve
an issue.
– Compromising: When both parties compromise for the sake of reaching an agreement.
– Smoothing: Problem played down and turns attention on what is important.
– Forcing: Forces the issue to be resolved by whatever is needed, not a great long-term
solution as effects team morale.
– Withdrawal: Means avoidance as it is hoped the problem will go away without being
dealt with.
5. Metrics
(Domain Problem Detection & Resolution)

9/9/19
25
Velocity/Throughput/Productivity
49
• 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
Burn Time
50
• 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

9/9/19
26
Cycle Time
51
• 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
52
• 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

9/9/19
27
Work In Progress (WIP)
53
• 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
Defect Detection Rate
54
• 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

9/9/19
28
Defect Closure Rate
55
• 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
EVM for Agile Projects
56
• 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

9/9/19
29
Earned Value Management Graphs
57
• 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”
6. Planning, Monitoring & Adapting
(Domain: Adaptive Planning)

9/9/19
30
Kanban/Task Board
59
• A Kanban board is a tool used to visualize the workflow that
enables the team to optimize 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.
Time-boxing
60
• 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.

9/9/19
31
WIP Limits
61
• 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 analyze 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
Release Planning
62
• 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 prioritized 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.

9/9/19
32
Iteration Planning
63
• Compared to the release planning, iteration planning is a lot more
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
1. Discuss user stories in backlog
2. Select user stories for backlog
3. Define acceptance criteria and write acceptance tests
4. Break down user stories into tasks
5. Estimate the tasks
Variance Analysis
64
• 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

9/9/19
33
Trend Analysis
65
• 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
Daily Stand Ups (DSU)
66
• 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:
1. What they did since last time they talked
2. What they plan on doing before the next meeting
3. Are there are impediments or blockers preventing them from
moving forward

9/9/19
34
Burn Down
67
• 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
Burn Up Charts
68
• 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

9/9/19
35
Cumulative Flow Diagrams
69
• 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 colored area of the chart equates to a workflow status
Backlog Grooming/Refinement
70
• This is the process of making sure the backlog is prioritized.
• It is the Product Owners responsibility to ensure the backlog is
refined correctly.
• The backlog stories are prioritized 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

9/9/19
36
Product-Feedback Loop
71
• 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
Control Limits
72
• 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

9/9/19
37
Pomodoro Technique
73
• TODO
7. Process Improvement
(Domain: Continuous Improvement)

9/9/19
38
Kaizen
• 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).
75
Retrospectives
• After each release/iteration, the Scrum Master/Team Leader should hold a
retrospective which can also be called an introspective.
• 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:
1. What is going well
2. What areas could be improved
3. 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 development
process providing immediate feedback on how the process is performing. If used
correctly retrospectives can result in: Improved capability; Improved quality
76

9/9/19
39
Retrospectives
• 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
77
Retrospectives
• Esther Derby and Diana Larsen defined a 5 step process for holding retrospectives
Step 1: Set the Stage: (cont.)
– 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 è IDEA
– Shoppers: look for useful info and happy go home with 1 idea è GOOD
– Vacationers: not interested in retro but happy to be away from work è BAD
– Prisoners: feel like being forced to attend è BAD
– 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 78

9/9/19
40
Retrospectives
retrospectives
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
• Color Coded Dots: Team uses sticky dots to show emotions where emotions ran
high/low during the iteration
• Mad, Sad, Glad: Team uses colored cards to describe emotional reactions during
iteration
79
Retrospectives
retrospectives
Step 2: Gather the Data (cont.)
– The team leader can use the following team based facilitation techniques to get more
interaction between team members:
• 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.
80

9/9/19
41
Retrospectives
retrospectives
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
81
Retrospectives
retrospectives
Step 3: Generate the Insights (cont.)
– Once the data on the iteration has been gathered it needs to be evaluated.
The data can be evaluated using the following brainstorming techniques:
• Prioritize 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
82

9/9/19
42
Retrospectives
retrospectives
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
categorized simply by choosing Keep/Drop/Add or Start/More/Less
83
Retrospectives
retrospectives
Step 4: 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
84

9/9/19
43
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 organization 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.
85
Process Tailoring/Hybrid Models (cont.)
• 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 recognize the value in the process
before deciding not suitable.
• For example, in XP there are multiple relationships dependent on
each other. 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.
86

9/9/19
44
Value Stream Mapping
• Value stream mapping is originally a Lean manufacturing technique to improve
processes. The process is as follows:
1. Identify Product: First thing is to identify the product, project, process you
want to improve
2. Create Map of Current Processes: Map out the process and how long each
process takes and the total process time
3. 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)
87
Value Stream Mapping (cont.)
• Value stream mapping is originally a Lean manufacturing technique to improve
processes. The process is as follows:
4. 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
5. Create Roadmap for New Process: Create a roadmap on how to implement
the proposed changes to the current process
6. 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
88

9/9/19
45
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 visualize 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
• Imagine the Failure
– The team brainstorms possible issues that could arise
– The facilitator can suggest scenarios
89
Pre-Mortem (Rule Setting, Failure Analysis) (cont.)
• The premortem is a facilitated team exercise that aims to identify the possible
failures on a project before they happen.
• 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
• 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
90

9/9/19
46
8. Product Quality
(Domain: Problem Detection and Resolution)
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
92

9/9/19
47
Continuous Integration
• 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
93
Exploratory Testing
• 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 behavior or edge
cases.
• Exploratory tests would usually be performed by an experienced
tester who are used to finding unknown issues and unexpected
behavior
94

9/9/19
48
Usability Tests
• 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
95
Risk Management
(Domain: Problem Detection and Resolution)

9/9/19
49
Schedule Risks
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:
1. 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)
2. 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)
3. 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)
97
Schedule Risks (cont.)
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:
4. 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)
5. 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).
6. Silver Bullet Syndrome (Just because a project is using Agile does not
mean it is destined for success, Agile projects fail too)
98

9/9/19
50
Schedule Risks (cont.)
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:
7. Research-oriented Development (The empirical nature of Agile
means the risk of running a research orientated project is
reduced)
8. Weak Personnel (Agile doesn’t affect this issue)
9. Contractor Failure (Agile doesn’t affect this issue)
10. Friction Between Developers and Customers (Agile doesn’t affect
this issue)
99
Risk Register
• 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
prioritized for next sprint.
100

9/9/19
51
Risk Adjusted Backlog
• This is when the Product Owner prioritizes 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
prioritized high on the backlog but if the risk had a minimum
impact and probability of happening it will be lower in the backlog
101
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
102

9/9/19
52
Risk-Based Spikes
• A risk-based spike is used to allow the team to eliminate or
minimize 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
103
Architectural Spike
• An architectural spike is when research/investigation needs to be
conducted on an area of the system, technology or application
104

9/9/19
53
Value-Based Prioritization
(Domain: Value Driven Delivery)
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 prioritize projects or stories based on a
common metric which removes bias theory using financial metrics
should be more accurate than other selection methods but they
can be manipulated to sway the outcome.
106

9/9/19
54
Net Present Value (NPV)
• TODO.
107
Return on Investment (ROI)
• Return on investment is the ratio of benefits from an investment
of the money invested expressed as a percentage.
• When prioritizing based solely on ROI always choose the project
story with higher ROI as the higher means the better return.
108

9/9/19
55
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
109
Agile Compliance
• 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
110

9/9/19
56
Customer Valued Prioritization
• This is simply keeping the product backlog prioritized
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
111
• MoSCoW
– Must Have
– Should Have
– Could Have
– Would like to Have
112

9/9/19
57
• Simple Schemes
– 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
113
• Monopoly Money
– 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 prioritizing
features as if prioritizing the entire backlog the stakeholders
might omit documentation or other tasks they don’t see the
immediate value in
114

9/9/19
58
• 100-Point Method
– 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
115
• Kano Analysis
– This technique categorizes features into 4 categories:
• Delighters/Exciters
• Satisfiers
• Dissatisfiers
• Indifferent
– This will help convey the features that bring the most customer
satisfaction
116

9/9/19
59
• 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
117
• Requirements Reviews
– 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 prioritize the work based on cost-
benefit analysis
118

9/9/19
60
• 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
119
• Relative Prioritization/Ranking
– With relative prioritization, it simply organizes 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.
120

9/9/19
61
Value-based Prioritization
• Financial Assessment Metrics
• Net Present Value (NPV)
• Return on Investment (ROI)
• Internal Rate of Return (IRR)
• Agile Compliance
• Customer Valued Prioritization
– MoSCoW - Simple Schemes
– Monopoly Money - 100 point Method
– Kano Analysis - Dot Voting or Multi – Voting
– Requirements Reviews - Minimal Viable Product (MVP)
– Relative Prioritization/Ranking
121
References
• 100 Powerful Agile Tools & Techniques to Conquer All Projects by
Shane Drumm
• PMI-ACP Exam Prep
2015 By Mike Griffiths,
PMI-ACP, PMP
122

9/9/19
62
Thank you for your attention!
123

PMI-ACP: 100 Agile Software Tools

Recommandé

Recommandé

Contenu connexe

Similaire à PMI-ACP: 100 Agile Software Tools

Similaire à PMI-ACP: 100 Agile Software Tools (20)

Plus de PhuocNT (Fresher.VN)

Plus de PhuocNT (Fresher.VN) (20)

Dernier

Dernier (20)

PMI-ACP: 100 Agile Software Tools