Important Notes

Domain I. Agile Principle and mindset Notes

1. The goal of agile leadership is to create an empowered and motivating work

environment in which people want to do what needs to be done.

2. Kanban teams use their WIP limits to control the number of items that can be in a
given stage of work at a time.

3. “Code standard” is an XP concept, not a Scrum concept; while a scrum team might
use such standards, and possibly even list the code standards themselves wouldn’t be
included in backlog list.

4. A phased and gated approach is associated with Waterfall. Phases are strictly linear
sequences of activities to build a product or deliver a project.

5. Planning and estimating during a feasibility stage is focused on determining value to

the customers by asking questions like, “What should we build?” As the project
progresses past the feasibility stage, the cost, the budget, and the overall project
schedule become clearer and easier to control.

6. ‘Barely sufficient’ is the agile term used to describe the approach of doing only as
much as is necessary to accomplish the work without including non-value added
activities.

7. The scrum value of commitment states ‘Because we have great control over our own
destiny, we are more committed to success’.

8. The rule of engagement, also known as ground rules or working agreements, provide
structure and boundaries for how team members.

9. The Scrum master is responsible for teaching others how to use the Scrum process to
deal with every new complexity encountered during a project.
10.Agile approach is an umbrella term that includes a diverse number of Agile methods,
practices, and techniques.

11.Every project is unique, but projects all have different requirements, uncertainty,
and risk.

12.As uncertainty and risk for a project increase, teams select project delivery life cycles
ranging from Predictive (non-Agile) approaches to Agile approaches.

13.The Agile Practice Guide identifies four types of project life cycle. Projects should
assess these to determine the best approach for project characteristics.

14.Predictive life cycles take advantage of high certainty around requirements, a stable
team, and low overall project risk. These projects are executed in a serial manner.

15.Iterative life cycles are optimized for speed of delivery. They focus on frequent
delivery of smaller deliverables.

16.Incremental life cycles optimize work to deliver value to customers more often than a
single, final product.

17.Increment delivery is an efficient way to deliver value earlier, reduce rework, and find
issues sooner. Although agile teams use it to deliver the customer’s top-priority
features first, it isn’t a prioritization method.

18.The practice guide represents a bridge to understanding the pathway from a

predictive approach to an agile approach.

19.The practice guide goes beyond addressing the use of agile in the computer software
development industry.

20.Agile techniques and approaches effectively manage disruptive technologies.

21.The first principle of agile places customer satisfaction as the highest priority and is
key in delivering products and services that delight customers
22.In order to stay competitive, organizations can no longer be internally focused but
rather need to focus outwardly to the customer experience.

23.Definable work projects are characterized by clear procedures that have proved
successful on similar projects in the past.

24.High-uncertainty projects have high rates of change, complexity, and risk.

25.Agile and Kanban are subsets of Lean. This is because they are named instances of
lean thinking that share lean concepts as: “focus on value, small batch sizes, &
elimination of waste”.

26.Agile manifesto values:

a. Individuals and interactions over processes and tools.

b. Working software over comprehensive documentation.

c. Customer collaboration over contract negotiation.

d. Responding to change over following a plan.

 Domain II. Value driven delivery Notes

1. Relative prioritization helps all the stakeholders understand the priority of the
features by showing the relative ranking of each user story or work item in relation to
all the others.

2. In test-drive development, the tests are written first, before the code. So the tests
will initially fail until the developers write the code and build the functionality that
the tests were designed to check.

3. In the MoSCoW prioritization scheme:

a- “Must haves” refers to the highest-priority, most fundamental requirements.

b- “Should have” refers to requirements that enable the system to work properly;
if we omit those features, the workarounds will be costly or cumbersome.
c- “Could have” refers to covers any useful additions that add tangible value to
the system but are not required.

4. The focus of the ATDD approach is testing whether the code behaves in a way that
meets the customer’s requirements.

5. A cumulative flow diagram that plots the flow of the work by individual activities can
help us identify the source of bottlenecks on a project.

6. When examining a cumulative flow diagram for bottlenecks, we look for a widening
band for an activity, which indicates the growing completion of work. A widening
band is created when one line is followed by another line of shallower gradient.

7. Continuous integration is the practice of regularly incorporating new code into the
code base and checking to make sure the system still works properly. This helps
reveal whether there are any problems in the code so they can be addressed
immediately.
8. Continuous integration Small batches of the source code are checked in, the control
system initiates a full build, a suite of automated is run, and developer is notified
electronically of any code compilation failures.

9. The test-driven development process of writing a test that initially fails, adding code
until the test passes, and then refactoring the code is known as either “Red, Green,
Refactor” or “red, Green, Clean”.

10.The main objective of ruthless testing is to ensure that product quality remains high
throughout the development process.

11.The requirement Prioritization Model is a prioritization scheme that involves rating

the benefit, penalty, cost, and risk associated with each of the features and using a
weighted formula to prioritize these features. This method relies on expert
judgement rather than on using questionnaires.

12.Defining the product vision, breaking it down into features, and prioritizing them
according to value, is referred to as ‘Value based analysis and decomposition’.

13.The S-curve is a tool commonly used to track project spending over time.
Its name is derived from the shape of the curve, which is the typical shape of project
expenditures over time.

14.The S-curve graphs are easy to interpret and quickly show whether the project is
over or under budget by displaying both the estimated and actual spending lines.

15.Risk, cost, value are all factors contributing to the decision of how items in the
product backlog should be prioritized.
 Domain III Stakeholders Engagement Notes

1. A decision spectrum is a tool that a team can use to help them make tough decisions
and reach convergence, or consensus.

2. A decision spectrum that include responses other than simply ‘yes’ or ‘no’ allows
each stakeholder to participate in the decision and render an opinion.

3. An agile charter would typically be shorter, less detailed, and more focused on how
the project will be run (the what, why, when, who, where, and how of the project)
than exactly what will be built.

4. Fist-of-five voting is a participatory decision-making model in which participants

show their level of agreement by voting with their fingers.

5. The collaboration game Prune the Product Tree involves drawing a tree on a flip
chart and adding the features as leaves at various points on the trunk and branches.
This exercise can help a team brainstorm how the features relate to each other and
to the existing functionality. [The goal of ‘Pruning the Product Tree’ collaboration
game is to gather and shape product requirement.

6. The collaborative game Remember the Future involves imagining that the project (or
a part of the project, such as a release) has been completed successfully.

7. Brainstorming is useful for many aspects of an agile project, including solving

problems, defining the product features, and identifying potential risks.

8. Agile models are lightweight sketches or diagrams that can be used to present a
proposed design, identify its issues and risks, and reach consensus about what will be
built. They aren't useful for confirming that the final product works as intended.
9. Wireframes are a type of lightweight model, typically a series of sketches or diagrams
that help the team share with their stakeholders how the product they are proposing
to build will function, in order to generate discussion and reach consensus.

10.Wireframes assist the project’s development by laying out content and functionality
so the project has a visual structure and basis for development.
 Domain IV. Team Performance Notes

1. Velocity is tracked in the same metric that the team used to estimate the work.
Agile teams can use any name they want for that metric, since it is a relative, rather
than an absolute unit of measure. So although "teddy bears" sounds like an unusual
way to estimate work, it would be perfectly appropriate from an agile standpoint.

2. Estimating units are used to track velocity; estimation tools should be relative ones.

3. Constructive disagreement is an important characteristic for a high-performing

team. (The other characteristics to look for are self-organizing, empowered,
consensus-driven, and trust-based.) High-performing teams aren't plan-driven or
value-based. We could say that a team's plans and priorities are value-based, but not
its people. Team diversity may present both challenges and opportunities, but it isn't
a requirement for high performance.

4. To estimate the finish date (at the current rate of progress) on a burn-down chart, we
extend the average downward slope of the progress line to see when it reaches zero.

5. Self-directing teams are empowered to create team norms and make technical
decisions.

6. Agile PMOs (Project Management Offices) are multi-disciplinary and invitation

oriented. PMOs should not be mandating Agile practices but should be tailoring their
engagement based on the needs of the teams applying agile techniques.

7. Organizational considerations for Project Agility include assessing the organizational

culture and structure, procurement management processes business practices and
the project management office.

8. Collaboration; everything about Agile should encourage collaboration, including

communication, co-location, self-organization, decision making, etc., collaboration is
integral to Agile projects.
9. Negotiation; is an important activity for Agile which yields productive results; plan,
schedule, features, changes, etc. are negotiable.

10.Active Listening; includes: listening, understanding, retaining and actively responding,

can reduce conflicts within the team.

11.Conflict Resolution; conflict should be resolved by searching for a “win-win” solution

through active listening and communication.

12.Servant Leadership; Leaders for Agile projects should practice servant leadership,
they are not in the command and control position but rather be a servant to enable
the team to perform well and model the right behavior.

13.Adaptive Leadership; the leader adapts to the environment to lead effectively, i.e. to
focus on value-adding activities.
 Domain V Adaptive Planning Notes

1. Spike is a time-boxed period designated to reduce uncertainty by learning about

a feature, technology, or process.

2. Spikes can be performed at any time during the project, whenever the team wants to
explore a risk or problem.

3. The purpose of performing an architectural spike is to perform a "proof of concept"

check to confirm whether the team's proposed technological approach will work.

4. Wideband Delphi is a potential alternative to use planning poker.

Both of these approaches allow us to create final estimates iteratively, counter bias,
and reach convergence.

5. Planning poker is a fast, efficient way to get reliable estimates for iteration planning.

6. The advantage of using coarse-grained requirements is that it allows us to focus on

the big picture.

7. Delay detailed product decisions until the last responsible moment.

8. During affinity estimating, we place user stories into columns according to their
estimated size.

9. A "requirements review" is another term for grooming or refining the backlog.

10.Discrete business-rule tests are the "confirmation" part of the three Cs (the three
components of a user story). These tests are explicit statements of the customer's
acceptance criteria that show whether a completed feature is working as intended.

11.T-shirt sizing is a high-level estimating technique that is used early in a project to

map out the overall effort that will be involved in the project.
12.Important formula

• Schedule Variance (SV) = Earned value (EV) − Planned value (PV)

• Cost Variance (CV) = Earned value (EV) − Actual cost (AC)

• Schedule Performance Index (SPI) = Earned value (EV) / planned value (PV)

• Cost Performance Index (CPI) = Earned value (EV) / actual cost (AC)

• Work In Progress = Lead Time (time period) * Average Completion Rate (units
per time period)

• Average Completion Rate = Work In Progress(units) / Lead Time (time period)

• Lead Time = Work In Progress (units) / Average Completion Rate (units per
time period)
 Domain VI Problem Detection Notes

1. Risks are uncertain events they have not yet happened.

• Issues are risk events that have occurred.
2. Defect cycle time is the amount of time between when the defect was discovered
and when the defect was fixed.
3. The Ishikawa or Fishbone diagram is one of the commonly used techniques to
identify the root cause of a problem and is mostly used in conjunction with the
5Whys Technique.
4. Control limits are used to detect signals that indicate when a process is not in
control, and therefore not operating predictably.
5. Control limits are the thresholds that determine whether a process is in or out of
control. A process is considered out of control when a data point exceeds a control
limit.
6. Escaped defects are the ones not found by the QA team, but by the end users post-
release.
7. Escaped defects have "escaped" being detected by the project's testing and
validation process. Escaped defects are not related to reviews, retrospectives, or
production processes outside of the project. Escaped defects are errors that are
missed by the quality assurance and make it into production.
8. WIP refers to those requirements the team has started working on but are not yet
complete. WIP limits are set to minimize sunk cost and waste.
9. A CFD helps track work at different stages, the total scope, amount of work that is
completed, and the amount of work in the in-progress state.
10.Waiting for the next deadline before we start working is an example of “student
syndrome.” While this certainly isn't the best way to work, it isn't one of Cockburn's
failure modes.
11.We calculate the expected monetary value (EMV) of the project threats, so we can
prioritize them along with the features in our product backlog to create a risk-
adjusted backlog.
12.Leading trends allow us to detect problems before they occur or when they are just
starting to happen.
13.Leading metrics help us adapt and re-plan based on emerging issues.
14.Lagging metrics provide a view of historical data, such as budget consumed to date.
They don't help us identify opportunities for improvement or give us insight into
future trends.
15.Metrics are important for evaluation of a project. The three major categories are
commonly used: Business Metrics, Process Metrics, and Project Testing Metrics.
16.A risk census is a simple framework for analyzing the risk exposure of a project.
17.Risk Board is an information radiator used to make the risks of a project transparent
to the team and the stakeholders.
18.Avoid, Mitigate, Transfer, and Accept are the four risk response strategies.
19.Risk Burn-down Chart is a simple graphical indicator of the risk trends in the project.
20.Risk Profile Graphs inform stakeholders if the project risks are increasing or
decreasing.
21.The risks identified through the risk management lifecycle are captured and tracked
in the Risk Log.
 Domain VII Continuous Improvement Notes

1. Process Analysis: The process of reviewing and diagnosing issues with a team's agile.
2. Process Tailoring: refers to customizing our agile methodology to fit the project
environment. (Agile Process Tailoring; ShuHaRi).
3. Releases, unit tests, acceptance tests, and daily scrums are all forms of agile reviews.
4. Retrospectives help improve capacity, productivity, and quality.
5. Setting the Stage for a Retrospective (Encourage participation, Set the ground rules,
define what people want from the retrospective, have people checking in with one or
two words & Working agreements for the retrospective).
6. Demonstrations, Prototypes, and Simulations are product feedback methods that
used to clarify requirements and uncover the need for new features in iteration or
release review meetings.
7. Value stream map identify delays, waste and constraints.
8. Project Pre-mortem Aims to find failure points before they happen.
9. Brainstorming Quiet writing, Round robin & Free for all.
10.Round Robin: Everyone in the team is given a chance to provide their views in a
Round Robin fashion.
11.Free for All: The team can participate without any restriction and provide inputs.
12.Quiet Writing: Team members write their ideas quietly and circulate to the
facilitator.
13.Fishbone Analysis known as a cause and effect diagram & Ishikawa diagram.
14.Kaizen is a Japanese word, which stands for ‘continuous improvement.
15.Shu – Follow the Rules. It means the teams that are newly implementing Agile must
aim to follow the guidelines provided by the methodology without tailoring any
process.
16.Ha – Branch out. The team has been using the guidelines and now has a good
understanding.
17.Ri – Find your own approach. It means that the team has gained sufficient mastery
and is creating its own practices and guidelines to suit the project dynamics.
18.Verification is looking for defects in the product to analyze how it differs from the
intended functionality.
19.Validation is to repeatedly check with stakeholders whether the product meets their
requirements.
20.Test-Driven Development (TDD) ensures developers create a detailed design Just in
Time (JIT) of writing the code. Ensures the code is tested often and as early as
possible.
21.Acceptance Test-Driven Development (ATDD) focuses on writing requirements in a
testable form.
22.Customer quality delivers value in the short term while Technical Quality enables
continuous delivery of value over time.
23.Quality best practices include verification and validation, usability testing, TDD,
ATDD, Definition of Done, and continuous integration.
24.Self-assessment is a process where an individual, an organization, or a team
conducts a comprehensive review of themselves to understand the strengths,
weaknesses, and opportunities to improve.
25.The risk exposure is the product of the likelihood of the risk occurring and the size of
loss if the risk occurs.