Interview questions for APM/SCRUM

1. Agile Vs waterfall?
Agile Waterfall
Work is divided into Sprints SDLC is done in distinct phases
Flexible Rigid

Iterative Liner/sequential
High degree of co-ordination between the Very less co-ordination
teams
Any requirements change can be easily Requirement changes needs to be take as a
adaptable change request
Testing and development goes concurrently Testing needs to be completed after the
development
Test plan is reviewed in every Sprint Test plan is hardly taken into consideration
PO sets the requirement for development Business Analysis prep the requirement

Agile and Waterfall are two different management methodologies best suited for different
types of projects. If you clearly understand the project outcomes from the beginning,
Waterfall may be the best fit. Waterfall is a better method when a project must meet strict
regulations as it requires deliverables for each phase before proceeding to the next one.

Alternatively, Agile is better suited for teams that plan on moving fast, experimenting with
direction and don’t know how the final project will look before they start. Agile is flexible and
requires a collaborative and self-motivated team, plus frequent check-ins with business
owners and stakeholders about the progress.

2. How do you handle Stakeholder Engagement?

In the context of Agile Project Management, stakeholder management plays a crucial

role. Let’s delve into this topic:
1. Definition of Stakeholders: Stakeholders are individuals or groups who have a
vested interest in the outcome of a project. They can be either internal (such as
employees, managers, and owners) or external (including customers, suppliers, and
government entities). Their feedback and perspectives significantly shape the
project’s objectives and outcomes1.
2. Scrum Guide’s Perspective: The Scrum Guide mentions stakeholders several times
but doesn’t delve into specifics. It emphasizes that the Scrum Team and stakeholders
should collaborate, information should be transparent to all stakeholders, and Sprint
Review participants include key stakeholders invited by the Product Owner. However,
the details remain somewhat vague2.

1
Interview questions for APM/SCRUM

3. Effective Stakeholder Management Approaches: As a Product Owner, consider

the following approaches for effective stakeholder management:
o Matrix of Influence:
 Classify stakeholders based on their power and interest:
 Crowd (Low interest / low power): Inform them about your product. Passive
communication (making information available) or active communication (sending
newsletters, version notes) suffices.
 Context setters (Low interest / high power): Although they may not show
much interest in your product, they can influence development efforts. Establish a
good relationship with them, considering possible connections between your
product and their domain.
 Subjects (High interest / low power): Engage with them actively. They care
about your product but lack significant influence.
 Players (High interest / high power): Invest substantial effort and time in your
relationship with them. They are both interested and influential2.
o Stakeholder Management Process:
 Identify Stakeholders: Recognize stakeholders based on their ability to:
 Provide a voice of reason.
 Facilitate change resulting from your project.
 Lead opinions.
 Remove impediments.
 Slow down or enhance your project.
 Impact your project3.
o Other Considerations:
 Analyze Stakeholders: Understand their needs, concerns, and expectations.
 Prioritize Stakeholders: Allocate resources and attention based on their
importance.
 Engage Stakeholders: Communicate effectively, manage expectations, and
involve them in decision-making.
 Scaling: Adapt these practices to your specific context4.

3. How would you deal with a difficult stakeholder?

The four strategies by which we can deal with difficult stakeholders are:

1. Listen to them carefully - Make an effort to comprehend their point of view. If what
they say aggravates you, consider whether their needs are in line with the project's
goals. Is it possible that they want things done a little differently? Make efforts to
discover some common ground. People desire to be understood and to believe that their
voices are heard.
2. Estimate their motivation - Try to understand the motivation behind the stakeholders’
opposition. This will allow you to compromise, and come up with a win-win solution, and
complete the project. Answer questions like - Are they reporting to a board of directors
that has its own reservations? What's the source of your stakeholders' sudden
opposition? Are they concerned about exceeding their budget? Concerned that the
project may not turn out as planned?
3. Meet them one after another - Meeting without other stakeholders in the room relieves
stress and allows the stakeholders’ to be more at ease. So, make time to meet with each
challenging stakeholder separately. This results in interactions becoming clearer and
calmer. Take advantage of this chance to learn more about their point of view and
recommended solutions. However, don't ask them why they don't like your plan outright.
Ask open-ended inquiries about their thoughts and how the project is moving instead.
4. Watch the stakeholders closely by identifying them - Determining the stakeholders
and finding out what inspires them should be the first step. Anyone who is influenced by
our work has control or influence over it or is interested in its success is referred to as a
stakeholder.

2
 Interview questions for APM/SCRUM

4. Types of waste in lean Management:

In Lean project management waste, or the Japanese term Muda, is defined as any activity or
process that doesn't add value to a product, but does add cost.
Lean's original Seven Forms of Waste include

TIM WOODS
 transportation,
 inventory,
 motion,
 waiting,
 overprocessing,
 overproduction, and
 defects. The new eighth form of waste is skills or non-utilized talent.
5. Milestones in Project

Milestones in Agile project keep on constantly changing due to iterative process and
continuous delivery.
However Agile sprint events like Sprint planning, Sprint review , sprint retrospective
serve as checkpoints to asses the progress and adapt strategies.

Detail description of the milestones:

1. Project kick-off: This is the initial phase where the project team is formed, and the
project goals, objectives, and requirements are defined. The project backlog is also
created during this phase.

2. Sprint planning: In this phase, the project team plans the work to be completed
during the upcoming sprint. The team selects user stories from the backlog and breaks
them down into tasks. The team also estimates the effort required for each task.

3. Sprint execution: This is the main development phase where the project team works
on completing the tasks identified in the sprint plan. The team holds daily stand-up
meetings to discuss progress, challenges, and plans for the day.

4. Sprint review: At the end of each sprint, the project team holds a review meeting to
demonstrate the completed work to stakeholders. Feedback is collected, and any
necessary adjustments or changes are made to the project backlog.

5. Sprint retrospective: After the sprint review, the project team holds a retrospective
meeting to reflect on the sprint and identify areas for improvement. The team
discusses what went well, what didn't go well, and any potential actions for
improvement in future sprints.

6. Release planning: This milestone involves planning for the release of the product or
project. The team identifies the user stories or features that will be included in the
release and creates a release plan.

7. Product release: This is the final milestone where the product or project is released
to the end-users or customers. The release may include new features, bug fixes, and
improvements based on the completed sprints.

It's important to note that Agile is an iterative and incremental approach, so these
milestones are repeated throughout the project lifecycle. The team continuously plans,
executes, reviews, and reflects on their work to deliver value to the stakeholders.

3
Interview questions for APM/SCRUM

6. Scrum of Scrums
Scrum of Scrums is a scaled agile technique that offers a way to connect multiple
teams who need to work together to deliver complex solutions. It helps teams develop
and deliver complex products through transparency, inspection, and adaptation, at
scale. It’s particularly successful when all high-performing scrum team members work
towards a common goal, have trust, respect, and are completely aligned.

7. Agile Manifesto

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation

 Customer collaboration over contract negotiation

 Responding to change over following a plan

8. What Is a Roadmap in Project Management?

Project management can be a challenging process, particularly when it comes to prioritizing
tasks to meet the goals of the project. That’s why it’s essential to have the right tools and
techniques to help you stay organized and focused.
One of the most valuable tools in a project manager’s arsenal is a roadmap.
A project roadmap is a graphical, high-level overview of the project’s goals
and deliverables presented on a timeline.

9. SDLC cycle

10.Kanban vs Scrum and which will you choose?

Scrum Kanban
Define Roles- PO, scrum Master, Scrum No defined roles

4
Interview questions for APM/SCRUM

Team
SDLC divided into Sprint which last 2-4 SDLC is continuous – not time boxing
weeks – Timeboxing event
Policy adoption is not taken into Policy can be adopted
consideration
Less flexible than Kanban More flexible
Artifacts – Product Backlog, Sprint Backlog, Kanban Board
Product increments
Three Pillars – Transparency, Inspection, Efficiency, effective, Predictable
adaption
Not that easy Easy in case of changing priorities
Generally used in development based Generally used in maintenance based
projects projects
Beneficial for implementing Scrum concepts Beneficial for completing project faster and
and focuses on Project Management focuses on improving workflows
Scrum Board gets cleared at the end of Board is not cleared until end of the project
each sprint and is prepared for next sprint

Kanban Should be use when:

 When priorities change frequently
 Limited no of work in WIP
 Limited work states for smooth flow
 Good for – Maintenance, production support or personal productivity project

Scrum :
 When there is defined timeframe for the work
 Have dedicated team.

11.What is Agile Manifesto? What are its values and principles?

The agile manifesto is basically a document consisting of values and principles that are
expressed in Agile. It was created in early 2001. It simply consists of 4 values and 12 key
principles. This manifesto helps the development team to work more efficiently and provides
a clear and measurable structure that promotes team collaboration, iterative development,
etc. It is specially designed to improve development methodologies.
The 4 Agile Values

1. Individuals and Interactions over Processes and Tools: It focuses on giving more
attention and importance to communication with clients.
2. Working Software over Comprehensive Documentation: It focuses on the
completion of the project and making sure that the project is completing the final
deliverables.
3. Customer Collaboration over Contract Negotiation: It focuses on involving
customers in all phases of the project so that the final product doesn’t lack any
requirement that the client needs. It is done to ensure 100% customer satisfaction.
4. Responding to Change over Following a Plan: It focuses on changes and
motivates the team to adopt the change quickly so that higher quality products can be
delivered. Therefore, agile works in short sprints so that changes can be utilized for
good.

The 12 Agile Principles

1. Customer Satisfaction: First priority is to fulfill customer demands to ensure 100%

customer satisfaction.

5
Interview questions for APM/SCRUM

2. Welcome Change: Changes are important for improvement therefore even late in the
development process, changes can be introduced and addressed throughout the
development period.
3. Deliver Frequently: Products have to be delivered as soon as possible therefore focus
on a shorter timescale.
4. Work Together: Both business stakeholders and team members work together through
the development process for better collaboration.
5. Motivated Team: For delivering high-quality products, team members are motivated
and encouraged. Team members are given the environment and support they need to
perform effectively.
6. Face-to-Face: Agile emphasizes Face-to-face communication which is the most
effective and efficient way of conveying information. It helps the team to communicate
simple and complex information in an effective way.
7. Working Software: Delivering working software to the customer is the major concern
of Agile. Working software or product is the primary measure of progress towards the
final product.
8. Constant Pace: Agile promotes sustainable development. All teams, sponsors,
developers, and users that are involved in the agile process should maintain a constant
speed to deliver working software in a short timescale.
9. Good Design: Focuses on good design and technical details to improve quality and
agility (quick and graceful).
10. Simplicity: Team focuses on tasks and features that are essential and reduces the
amount of work and time spent on complex features and tasks that are not essential. It
is done to keep things simple.
11. Self-Organization: Agile team should be cross-functional and self-organized. It should
not depend on the manager to assign work, instead should find their own work and
manage the responsibilities and timelines. Such teams not only help to deliver good
quality software but also provide the best designs, requirements, and architectures.
12. Reflect and Adjust: To improve the effectiveness of a team, the team reflects on how
to become more effective and assess their working style at regular intervals. This is
done so that one can learn from their mistakes and take some steps to improve their
performance in the next iterations.

12. What do you understand by scope creep and how can you managed?
Scope creep is used to describe how a project's requirements tend to grow over time, like - a
single deliverable product becomes five when a product with three essential features
becomes ten, or when the customer's needs change midway through a project, requiring a
reassessment of the project requirements. Changes in project needs from internal
miscommunication and disagreements, and key stakeholders are some of the common
causes of scope creep.

To manage scope creep, we need to use the change control mechanism to keep it under
control. This includes the following -
 Maintaining a baseline scope and keeping track of the project's progress.
 To evaluate actual work performance metrics to the baseline scope, i.e., "How
different is the current project from the original plan?", we need to perform Variance
analysis.
 Identifying the severity and source of the observed alterations.
 Selecting whether to take preventive or corrective action in response to requests
regarding changes.
 To recommend actions and manage all change requests by using the Perform
Integrated Change Control method (whether preventive or corrective).

13. What is burn Up and Burn -down Chart?

Burn-up Chart: It is the chart that display the amount of work that has been completed in the
project and the total amount of work for the sprint of that iteration

6
Interview questions for APM/SCRUM

Burn- down Chart – It is the chart that displays the amount of work that is remaining to be
completed in the project.

14. What are the different types of burn-down chart?

Different types of Burn-Down charts are listed below:

1. Product Burndown Chart: It is a type of chart that is used to show story points of
each completed sprint so that it depicts the completion of requirements over time. It
mainly shows how many of the product goals are being achieved by the team and how
much work is remaining.
2. Sprint Burndown Chart: It is a type of chart that is used to show the remaining works
for the scrum team of a particular sprint. It makes the work of the team visible and
shows the rate at which work is completed and how much is remaining to be
completed.
3. Release Burndown Chart: It is a type of chart that is used to show how a team is
progressing against the work for a release. This chart is updated by the scrum team at
the end of each sprint. It is very essential to see what process is being made during
each sprint.
4. Defect Burndown Chart: It is a type of chart that is used to show the total number of
defects that are being identified and fixed or removed.

15. Explain TimeBoxing in Scrum.

Timeboxing is an important time management technique or tool that is used to limit the
amount of time that is being spent to complete a task. It simply allows a fixed unit of time for
each and every task and this unit is known as a time box. The maximum length of the time
box is 15 minutes. It not only helps to improve focus but also results in an increase in
productivity. There are some events in Scrum and all these events are timeboxed which
means all these events are allotted with a maximum and fixed unit of time for the task. The
events that are time-boxed are listed below:

 Sprint
 Sprint Planning
 Daily Scrum
 Sprint Review
 Sprint retrospective

16. Explain the term “impediments” in Scrum.

Impediments are something that blocks or stops the progress of teamwork. It causes the
team not able to perform their task in a better way and on time that in turn also slows down
the velocity. It’s the responsibility of the Scrum master to remove or resolve impediments.
Impediments can be anything as listed below:

 Missing resource
 Strict boss or team member
 Technical or operational issue
 Power outage
 Lack of understanding about agile or scrum
 External issues such as war, weather, etc.
 Business problems

7
Interview questions for APM/SCRUM

17. What is the main role of Sashimi in Scrum?

Sashimi is basically a Japanese word whose meaning is pierced body. In scrum, Sashimi is a
technique that is simply used to check whether all functions (every phase of the software
development cycle) are completed or not after the product is displayed. Functions include
requirement analysis, planning, design, development, testing, and documentation.

18. What are standard or common metrics for Agile? Explain.

Agile Metrics are basically standard metrics that are used to measure the work of the team.
These metrics are used to determine the quality of work, productivity, progress, team health,
etc. Its main focus is on value delivered to customers and how much end-users were
impacted by it.
Standard Metrics for the Agile project

1. Velocity: It measures the amount of work done by the development team during a
sprint. It gives ideas about progress, capacity, etc.
2. Cumulative Flow Diagram: It is a flow diagram used to measure the current status
of work in progress of the team. It is simply used to track the progress of agile teams
and manage flow stability.
3. Defect Removal Awareness: It is used to measure the ability of the development
team to remove defects prior to release. It helps to maintain the quality of products by
a working team.
4. Work Category Allocation: It is used to measure where we are spending or
investing our time so that we can adjust our priorities.
5. Sprint Burndown Metric: It is used to measure the total number of sprints or tasks
that are completed as compared to estimated scrum tasks. It usually tracks the
progress being made on tasks during a Sprint.
6. Defect Resolution Time: It is used to measure the time taken by the team to
identify and fix the defects or bugs in the software. There are several processes
involved in fixing bugs.
7. Time Coverage or Code Coverage: It is used to measure the time that is given to
code during testing. It helps one to understand how much code is tested and also
helps in assessing the test performance.
8. Business Value Delivered: It is used to measure the efficiency of the working
team.

19. Why aren't the user stories' man-hours estimated?

 Usually, the efforts are estimated in clock-hours.

 It’s difficult to estimate legacy work.
 If one resource gives estimates and the other works, then the estimation is useless.
 The estimation depends upon the experience level.
 Team usually exaggerate the difficulties they may face and consider the best case
scenario

Advantage of estimating in SP
 There is no co-relation between the estimator skills and experience and SP are
independent of the Author’s story
 Because SP are measurement of relative sizes and relative sizes cannot be changed
due to external forces , team members can estimate accurately
 SP encourages collaboration by prioritizing the team behavior over individual
behavior
 It helps in tea building activity because team exchange argue , constructively criticize
and have fun while playing poker cards for estimation

8
Interview questions for APM/SCRUM

20. How is estimation done in a project ?

Estimation is done on the basis of complexity and asses of scales
 T shirt Size
 Fibonacci series
 Numeric sizing
 Dog breed

21. What are the some risks in scrum? How they are handled?
 Budget
 People
 Sprint
 Product
 Knowledge and capility
Managing risks involves identifying, assessing, analyzing, defining and implementing risk,
managing risk and monitoring risk

22. Agile reports

1. Sprint Burndown
At a Sprint-level, the burndown presents the easiest way to track and report status (the
proverbial Red/Amber/Green), i.e., whether your Sprint is on or off-track, and what are the
chances of meeting the Sprint goals. The burndown chart – when used right – can
provide near-real time updates on Sprint progress.
“If your team do it right, then they would take in just the right amount of work into a sprint.”
At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on
development work worth a certain number of Story points. This forms the basis for the Sprint
Burndown chart.
The total story points agreed at the beginning of the sprint make up the y-axis, and the
individual dates in the Sprint make up x-axis. If your team do it right, then they would take in
just the right amount of work into a sprint. And if everything goes well, the burndown trend
will look like this:

Figure 1: Ideal Sprint Burndown Chart

Of course, not all sprints are made equal. So actual Sprint Burndown may not look as perfect.
For instance, Scrum teams are prone to overestimate their ability to deliver during their first
development Sprint on a new project. Or if they are a newly formed team. Or if they are
learning to work Scrum. In such cases, it’s quite possible that the team fall behind schedule.
The burndown chart helps bring issues to the surface:

9
Interview questions for APM/SCRUM

Figure 2: When the team are off track during a Sprint

As you can see, this particular team needed a spike late in the Sprint to catch up. This is not
uncommon, and the reasons could be many – the team overestimated, or development
stalled due to technical constraints. Ideally, such trends should be avoided.

2. Sprint Velocity
This metric goes hand in hand to help your team achieve ideal Sprint burndown.
How?

In simple words, Sprint Velocity represents the average number of story points a team
can take on for a Sprint. This number is based on observing how many story points were
delivered during the previous two to three Sprints, and simply calculating the average story
points delivered per sprint.
When you know your team’s velocity, it is then going to be easy to manage how much work
they can commit to at the beginning of a Sprint. Keeping track of Sprint Velocity will help you
and your team avoid situations where you need to reduce or change scope mid-sprint – which
may not make them (or you) look good.

The obvious limitation with Velocity is that you need at least two to three Sprints’ worth
progress before you can identify a trend.
When it’s too early to know your team’s Velocity.
During the first few sprints, I try to avoid the off track scenario (like in Figure 2 above) by
looking at velocity from past Agile projects my team have been part of.
Where velocity data is available for past (similar) projects, and if the team are
experienced enough in Agile to employ consistent story pointing across projects, then you
can begin new projects like a boss, and get the team to accept reasonably accurate story
points right from the get go.
Again, velocity can differ between projects – even for the same team. So while this technique
might improve accuracy in Sprint Planning during the first few sprints, it is not fool proof. So
there’s that.

3. Epic, Product and Release Burndown

We know now that Sprint burndowns help you track status at Sprint-level. Epic, Product and
Release burndown charts provide a similar utility.

Figure 3 – Sample Release Burndown Chart

10
Interview questions for APM/SCRUM

As with Sprint burndown, Release-level burndown charts help you understand when you can
expect to deliver a given scope. And again, note that the accuracy of the burndown improves
with time, as the team deliver the first few sprints.
“It is quite rare for Agile projects to have the entire scope nailed right at the beginning (like
Waterfall), so learn to accept spikes as a matter of course.”
As you can see from Figure 3, the sample release burndown is not an ‘ideal’ trend line like
Figure 1. Around Sprints 2 and 3, the team have (seemingly) added new requirements to the
release backlog. This has led to a spike in the blue line around sprint 3, before settling back to
a more stable burndown trend.

Any experienced Agile practitioner will tell you such spikes in the burndown trend line
are quite common in real life Agile projects. By nature, Agile allows you to groom the
backlog regularly to increase or decrease scope. It is then only natural that such grooming
reflects in your burndown charts. It is quite rare for Agile projects to have the entire scope
nailed right at the beginning (like Waterfall), so learn to accept spikes as a matter of course.
Or, Use Burnup Charts instead
There are limitations with Burndown charts. They don’t bring out issues such as scope creep
as clearly for all stakeholders to understand.
Why is this important?

Let’s take the release burndown depicted in Figure 3 earlier as a case in point. The spike
around sprint 3 depicts what looks like a bit of scope creep. This has led to a not-so-straight
trend line, with a projection that is delivering noticeably later than the team could have
before the spike. The impact of the change in scope isn’t entirely clear to an onlooker.
For a senior stakeholder that sits outside the project, it may not be immediately apparent
that the team are doing more than they set out to plan. Therefore, the causes for any
delays in the project schedule aren’t understood as well as they could be with better
information.
A burnup chart could help you here. Let’s see how with an example:

Figure 4 – Sample Burnup Chart

Credit
A burnup chart plots two key pieces of information – total work (hours, story points etc.)
and completed effort (progress against total work). In the example in Figure 4, you can see
that the Scope (i.e., total work) changes constantly (red line). In fact, it is expected to have
changed as much as 30% by the end of the iteration (sprint).
You can also see that actual effort has progressed steadily along the blue line. From a quick
glance, the following will be clear to anyone:
The scope of work for the iteration (sprint) has changed by as much as 30% through the
iteration.
The team set out to deliver 140 hours’ effort, and are on track to deliver 160 – i.e. they
are delivering about 15% more than they originally committed.
Despite the increased productivity, the team will still fall short of the (changed) scope for the
iteration (sprint).
What possible actions could be considered?
Better scope management – so the team don’t have to factor changes day-to-day, and
therefore lose effort in realigning with new scope constantly.

11
Interview questions for APM/SCRUM

Better upfront iteration (sprint) management – so the product owner can work with the
team more effectively to produce a more concrete sprint backlog at the beginning of the
iteration (sprint).
Now, could you have surmised all that with just the green line in figure 4, or the spike in the
blue line in figure 3? Highly unlikely. That is the power of the burnup chart.
Choose burnup or burndown mindfully – or better yet, choose both!
When your release/sprint scope isn’t stable enough, switching from a burndown to a burnup
chart will help you identify and report risks and issues more effectively. If on the other hand,
your backlog is pretty stable up front, and you don’t see the scope changing regularly,
burndown charts will be sufficient to report progress.
4. Earned Value
Now this is one of the Agile reporting techniques I am just a little hesitant to recommend.
Let me explain.
If you don’t know Earned Value reporting, it’s basically about measuring whether the
amount of money spent through so far in your project justifies the amount of work
completed at this point in time.
There are a few variables here:
Budget – the estimated cost of your project. This is usually decided at the beginning of the
project, and reviewed infrequently or not at all.
Actual cost (AC) – the proportion of the original budget your team have spent so far.
Planned Value (PV) – the proportion of your project scope that was expected to have been
delivered by this time.
Earned Value (EV) – the ‘real’ value of the scope that has actually been delivered so far.
Let’s consider the sample EV graph below:

Figure 5: Sample Earned Value Graph

Credit
At t1, the team has delivered more Earned Value compared to budget spent (Actual Cost), so
EV > AC.
At t2, the team has delivered less Earned Value compared to budget spent (Actual Cost), so
EV < AC.
What does this imply?
Not much, really – or a lot, depending on your situation.
If for example, you’ve technically only delivered 50% of your project scope but already spent
60% of the original budget,
This could mean your team aren’t efficient – after all, you’ve spent more than you earned.
It could also mean you budgeted incorrectly in the beginning – being Agile and all, the initial
budget would have been a ballpark estimate.
Again, it could be that your team have completed much foundation work during the initial
phases of the project that ultimately, EV will catch up to AC.
Or, your scope could have changed substantially to justify the additional spend (re-alignment)
at the given point in time.
Unless you truly understand the root cause of a variance in EV vs AC, it will be hard to judge
whether your Earned Value at a point in time is acceptable. Especially given the

12
Interview questions for APM/SCRUM

nature of Agile projects in general, it is unfair to expect the level of certainty necessary to get
budget and scope right up front.
So use this metric – if only to keep an eye on how much money your project is spending
relative to progress. Just don’t rely too much on it – it might take you back to Waterfall. Which
isn’t a bad thing in itself – however, be careful not to confuse Agile and Waterfall.

5. Scope Change
This is a bit of an oxymoron. By nature, Agile projects should be open to scope change. Right?
Right?
Yeah, not so much.
If your project is in churn all the time, you’ll find your team constantly working to re-align with
new requirements, dropped requirements, changes etc. If the project scope reduces
significantly as part of all this churn, it could mean you can deliver earlier than planned. If on
the other hand, there is significant addition to scope or if the scope has changed so much you
need a lot of rework, then all of a sudden, your project could be in the red because the
original schedule now looks like Mt. Kilimanjaro.
So what do you do in such scenarios?
You report the changes to scope regularly, of course. Agile projects can absorb changes
to scope. They should also report such scope changes diligently.
Did your Product Owner drop Feature number 4 mid-flight and bring in a Feature number 6
that costs twice as much – in time and money? You need to report this so you can secure the
additional funding and time necessary to absorb the changes.
By reporting Scope Changes, you demand a certain level of responsibility on the part
of the Product Owner. They have the responsibility to think any significant changes
through before these are introduced to the project, so they can be prepared to answer any
questions about cost/scope creep.

6. Defects Trend
Plot defects as they are identified, their resolution and those that remain open on a graph,
and you’ll have yourself a visual Defects Trend chart. Defects Trends are useful in tracking
defects resolution for a release or product as a whole.
Not all defects may be fixed within the Sprint or Release they are identified. Some
(usually non-blocker defects) tend to get carried into future Sprints or Releases.

Figure 6 – Sample Defects Trend

Plotting and tracking the Defects trend will help your team in a number of ways:
You can manage code quality as you get closer to a release.
The trend will help you decide if you need a Defects spike.
Making defects trends visual brings a sense of urgency and accountability among developers,
who will (hopefully) work to improve code quality.

7. Team Capacity/Load
Whether you’re starting out with Agile Transformation, or if you’re at various stages of getting
there, the most challenging Agile tenet is not having team members spread on multiple
projects.
“Even more challenging is to know if everyone in your team is working to optimal capacity.”

13
Interview questions for APM/SCRUM

While Agile doesn’t allow sloths to survive – it exposes them eventually – we’re not talking
about work shirkers here.
You do genuinely need a way to know – at any point in time – what everyone in your team
is up to. The Team Capacity/load dashboard can help with providing you a snapshot of your
team’s workload.
How does it work?
For each team member on a project, capture the following information:
Total capacity in hours = number of hours per day that they are able to dedicate to the
project multiplied by number of days that they are allocated to the project.
Assigned capacity in hours = number of hours (or story points multiplied by average
number of hours per story point for the team member’s particular skill) allocated.
Available capacity in hours = Total capacity – Assigned capacity
Having this information to hand will help manage your team’s allocation better –
especially when they are across multiple projects.
Tools like JIRA offer a number of plug-ins to manage Team Capacity/Load online, so you have
on demand access to the latest view of work distribution and capacity.
What do your stakeholders look for in an Agile Report?
What single question do you need to answer with all your reports?
Simple: Are You On Track?
This is almost everything anybody that consumes your report, wants to know. Almost.
Agile or Waterfall, whatever metrics or report templates you use, you are trying to report on
this one super-metric. Remember – as long as your reports provide a visible and clear
answer to this question, you will have done your job. All else is either exceptional or
supporting information, or just plain background noise.
“Almost all the Agile or scrum reports above can be set up once, and generated on demand in
a matter of seconds or minutes.”

23. What is MVP, MMP,MMR?

MVP MMP MMR
1 Minimum Viable Product Minimal Marketable Product Minimum Marketable
release
2 Lean Startup concepts that Minimal number of features is a product release with the
stresses the impact of learning that address the fewest features possible that
while performing product requirement of the user address your customers'
development current new needs
3 It allows one to test and Helps organization to reduce MMRs are used to reduce
understand by the idea getting time to the market the time it takes to market
exposed to the users between releases by
condensing each release's
coherent feature set to the
smallest increment that
provides new value to
customer
4 One has to collect all the
relevant data and learn from the
collected data
5 The thought of MVP is to being
able to produce the product, to
provide access to the users and
to observe how the product is
perceived and understood.
Basically to provide more insight
on the customer needs

14
Interview questions for APM/SCRUM

24. What is product roadmap?

 A product map is tool which indicates how the product will look over the time.
 It gives the holistic view of product features which the correct product vision
 It also indicates the development, goals that the product will achieve , problems
that product will solve.
 It is managed by product manager . it helps the team members to work together to
achieve the desired goal.

25. What are the different types of methodology in agile?

 Scrum
 Kanban
 FDD
 CRYSTAL
 Lean
 Test Driven
 Adaptive System development
 Dynamic Software Development Method
 XP – extreme Programming

26. What are the three C’s in an User Story?

Card: It is a written account of the story that is utilized to plan and estimate. To keep user
stories succinct, they are manually written on index "cards."
Conversation: The Conversation is required to learn more about the Card. The conversation
encourages the agile team to work together in small steps to develop a shared understanding
of the problem and potential solutions.
Confirmation: Confirmation is an acceptance criteria that contains the fundamental
requirements and turns them into test criteria so that we can determine when the user story
has been properly provided.

27. . What is Scrum?

Scrum is an Agile framework that can help teams work together. Scrum can enable teams to
learn from experiences, self-organize while working on problems, to reflect on their victories
and failures, to make improvements. This Agile Scrum interview question is often used as a
starter question to get the interview moving.

28. Define the roles in Scrum?

 Product Owner: The product owner is an individual who is responsible for increasing the
ROI by determining product features, prioritizing these features into a list, what needs to
be focused on the upcoming sprint, and much more. These are constantly re-prioritized
and refined.
 Scrum Master: This individual helps the team in learning to apply Scrum to ensure
optimum business value. The scrum master removes impediments, shields the team from
distractions, and enables them to adopt agile practices.
 Scrum Team: They are a collection of individuals who work together to ensure that the
requirements of the stakeholders are delivered.

29. What are the responsibilities of the Scrum Team?

The Scrum Team is one that’s self-organizing and involves five to seven members. The
following are their responsibilities:
 Working products must be developed and delivered during each sprint.

15
Interview questions for APM/SCRUM

 Ownership and transparency must be ensured for the work assigned to the team
members.
 Correct and crisp information must be provided to ensure a successful daily scrum
meeting.
 They must collaborate with the team and themselves.

30. What are the Artifacts of the Scrum Process?

 Product Backlog: It is a list that consists of new features, changes to features, bug
fixes, changes to the infrastructure, and other activities to ensure a particular output
can be obtained.
 Sprint Backlog: It is a subset of the product backlog that contains tasks focused on by
the team to satisfy the sprint goal. Teams first identify the tasks to be completed from
the product backlog. These are then added to the sprint backlog.
 Product Increment: It is a combination of all product backlog items completed in a
sprint and the value of previous sprints' increments. The output must be in usable
condition, even if the product owner doesn’t release it.

31. How are the Product and Sprint Backlog different from One Another?
Product Backlog Sprint Backlog
1 It is a list of items that need to be completed It is a list of items to be completed during
for developing the product each sprint

2 The backlog is collected from the customer The team collects the backlog from the
by the product owner and assigned to the product owner and sets up the time
team frame for the sprint

3 It has a specific end goal It is specific to a sprint

4 Based on customer vision Can vary based on product vision defined
by the product owner

5 It’s independent of the sprint backlog It’s dependent on the product backlog

6 The product owner maintains the backlog Each new sprint has backlogs added by
until the project is complete the team

32. Who is a Scrum Master? And what does he/she do?

A Scrum Master is someone who promotes and supports the usage of Scrum within the team.
 He/She understands the theory, practices, rules and, values of Scrum
 He/She ensures that the team follows the values, principles and, practices of Scrum
 They remove any distractions and impediments that hamper the progress of
the project
 The Scrum Master ensures that the team delivers value during the sprint

33. What happens in Daily Stand-up sessions?

Stand-up sessions are daily discussions that take place and are usually 15 minutes long. Daily
Stand-up sessions help understand:
 What tasks went well
 What tasks were completed

16
Interview questions for APM/SCRUM

 What tasks are pending, and

 The obstacles the team is facing
The meeting helps in understanding the overall scope and status of the project. Further
discussions can take place after the stand-up sessions.

34. What is Scrum-ban?

 Scrum-ban is a methodology that’s a combination of Scrum and Kanban. Scrum-ban
can be used to meet the needs of the team, and to minimize the batching of work, and
to adopt a pull-based system.
 It ingeniously includes the structure of Scrum and the flexibility and visualization of
Kanban.

35. What is Sprint 0 and Spike?

 Sprint 0 refers to the small amount of effort put in to create a rough skeleton of the
product backlog. It also includes insights towards estimating the release of products.
Sprint 0 is required for:
 Creating the project skeleton, along with research spikes
 Keeping minimal design
 Developing some stories completely
 Having low velocity and being lightweight
 The spike is a set of activities that involve Extreme Programming (XP) for research,
design, investigation, creating POCs, etc.
 The spike aims to reduce risks of the technical approach, helping gain knowledge to
better understand requirements and improve reliability

36. What is ‘Scrum of Scrums’?

 It is a terminology used for scaled agile technologies, which is required to control and
collaborate with multiple scrum teams. It is best used in situations where teams are
collaborating on complex assignments.
 It is also used to ensure that the required transparency, collaboration, adaption, and
adoption are established and to ensure that the products are deployed and delivered.

37. What is User-Story Mapping?

 User story mapping represents and arranges user stories that help with understanding
system functionalities, system backlog, planning releases, and providing value to
customers.
 They arrange user stories based on their priority on the horizontal axis. On the
vertical axis, they are represented based on the increasing levels of sophistication.

38. What happens in a Sprint Retrospective?

The sprint retrospective takes place after the sprint review. During this meeting, past
mistakes, potential issues, and new methods to handle them are discussed. This data is
incorporated into the planning of a new sprint.

39. What is Empirical Process Control in Scrum?

 Empiricism refers to work that’s based on facts, experiences, evidence, observations,
and experimentation. It is established and followed in Scrum to ensure project
progress and interpretation is based on facts of observations.
 It relies on transparency, observation, and adaption.
 The mindset of the team and the shift in thought process and culture are essential to
achieve the agility required by the organization.

17
Interview questions for APM/SCRUM

40. What are Some drawbacks to using Scrum?

 Scrum requires individuals with experience
 Teams need to be collaborative and committed to ensuring results
 A scrum master with lesser experience can cause the collapse of the project
 Tasks need to be well defined, lest the project has many inaccuracies
 It works better for smaller projects and is difficult to scale to larger, more complex
projects

41. What are the key skills of a Scrum Master?

 A strong understanding of Scrum and Agile concepts
 Fine-tuned organizational skills
 Familiarity with the technology used by the team
 To be able to coach and teach the team to follow Scrum practices
 Having the ability to handle conflicts and resolve them quickly
 To be a servant leader

42. How can discord be dealt with within the Scrum Team?
 The issue’s root cause needs to be identified and addressed
 Complete ownership needs to be established
 Try to diffuse the disagreement
 Emphasize on focus areas that complement the project
 A common understanding needs to be established to guide the team
 Performing continuous monitoring and providing complete visibility

43. What is a User Story?

 A user story is an agile software development/ project management tool that provides
teams with simple, natural language explanations of one or more features of the
project that’s written from the perspective of the end-user.
 The user story doesn’t go into detail but only mentions how certain types of work will
bring value to the end-user. The end-user, in this case, could be an external
component or an internal customer/colleague within the organization.
 They also form the building block of agile frameworks like epics and other initiatives.
 They ensure that the teams work towards the goals of the organization, with the help
of epics and initiatives.
 The requirements to make a user story a reality are added later, after discussions with
the team.
 They are recorded on post-it notes, index cards, or project management software.

44. How are user stories, epics, and tasks different?

 User Stories: They provide the team with simple explanations of the business’
requirements created from the end user's perspective.
 Epics: An epic is a collection of related user stories. They are usually large and
complex.
 Tasks: Tasks are used to break down user stories further. They’re the smallest unit in
Scrum that is used to track work. A person or a team of two people usually work on a
task.

45. What is a Sprint?

 Sprint is a terminology used in Scrum, used to describe a time-boxed iteration.
 During a sprint, a specific module or feature of the product is created.
 The duration of a sprint can vary between a week or two.

18
Interview questions for APM/SCRUM

46. What are the responsibilities of a Product Owner?

 Defines the vision for the project
 Anticipates the needs of the customer and creates appropriate user stories
 Evaluates project progress
 Acts as a liaison for all product-related questions

47. What is a Burnup and Burndown Chart?

 A burnup chart is a tool that’s used to track the amount of work that’s been completed
and to represent the total amount of work that needs to be done for a sprint/project.
 A burndown chart represents how fast working through user stories is. It shows total
effort against the amount of work for each iteration.

48. How is Estimation Done in a Scrum Project?

 The estimation of user stories is done based on their difficulty
 A particular scale is used to assess the difficulty of the user stories. Some type of
scales are:
 Numeric Sizing (1 - 10)
 T-shirt Sizes (S, M, L, XL…)
 Fibonacci Series (1, 2, 3, 5, 8…)
 Dog breeds (Great Dane, Chihuahua…)

49. What is the value stream

Value Stream Leadership in SAFe VSM is not easy. It entails the disciplined, ongoing
application of the five principles of Lean thinking throughout each value stream. This, of
course, requires the time, expertise, and dedication of key individuals. Many organizations
have appointed a Value Stream Manager—a role inherited from manufacturing—to serve in
this capacity. A Value Stream Manager has the following characteristics: Lean mindset – They
understand the principles of Lean thinking and how to apply them to improve value stream
flow. Business knowledge – They understand the customer needs, market forces, and
compliance factors that shape product strategy and define value metrics that guide product
delivery. Technical knowledge – They understand which products, services, and supporting
tools will produce the solutions with the most business value. Process knowledge – They
understand the sequence of activities across the organization that turns ideas into valuable
solutions. Strategic influence – They evangelize, support, enable, and secure funding for
value stream improvements. Tactical influence – They identify needed improvements,
mobilize teams, lead change, and regularly measure results.

RAID is an acronym used to imply Risks, Actions, Issues, and Decisions. The RAID is one of the
most important tools for a Project Manager.
In order to track risks, take actions, tackle issues, and make decisions, the Project Manager
uses the RAID tool.

50.What is RAID in project management and why is it necessary to create a RAID

log?
Ans. RAID is an acronym for Risk, Assumptions, Issues, and Dependencies. A RAID log is
important for a project manager to track anything that would impact a project now or in the
future.

19
Interview questions for APM/SCRUM

51. What are some risks in Scrum? How are they handled?
Some types of risks in Scrum are:
 Budget: The risk of exceeding budgets
 People (team): Team members need to be of appropriate skill and capability
 Sprint (duration and deliverables): Exceeding the duration, addition of the scope of
work
 Product (user stories, epics): Having ill-defined user stories and epics
 Knowledge and capability: Having the appropriate resources
 Managing risks involves identifying, assessing, analyzing, defining, and implementing
risk responses, monitoring, and managing them. These are done on a continual basis
right from the starting of the project until completion. It is essential to understand that
the impact of the risk is based on the proximity of the actual occurrence of the risk.

52.20 MAIN PROJECT RISK EXAMPLES AND THEIR MITIGATION STRATEGIES

To begin with, the 20 main project risk examples and how to mitigate these risks will be
discussed in the upcoming paragraphs.
1. Purpose and Need not well-defined: The first project risk example is the risk related
to the need and purpose of the project. This is a medium type of risk but it can get
transferred to the high project risk category if the project is impacted by this factor.
Mitigation: Any organization needs to complete a business case, or the planning artifacts to
be prepared if it is not provided beforehand. Also, the need and purpose of the project have
to be mentioned and defined accurately.
2. Incomplete project design and deliverable definition: The second project risk
example is incomplete project design and deliverable definition. It is a low-risk factor but can
eventually become a high-risk factor if not controlled beforehand.
Mitigation: It is always beneficial to appoint a subject matter expert to prevent such a risk.
The experts will help you define the project by conducting design workshops. This way, the
risk can be prevented efficiently.
3. Difficulty in defining and understanding project schedule: Every project must have
a specific completion period. If there is no set schedule or if there is difficulty in
understanding the project schedule then this project risk example will arise. It is included in
the low-risk category but can cause a medium risk to the project.
Mitigation: Workshops are really important in such cases. All should conduct scheduled
workshops with the team members. This will help them manage time efficiently and also
avoid missing tasks.
4. Risks related to budget: There may be times when the costs go beyond the revenue,
and in such scenarios, this project risk example arises. There may be uncertainty in every
business activity related to the future, and when the cost exceeds revenue, the risk factor
becomes severe.
Mitigation: To prevent such risks, all should analyze the external factors and the internal
factors that hinder the project’s working and keep some cash aside for meeting the crisis
soon.
5. Resistance to changes: This is another project risk example in which if a project does
not implement changes with the changing trends, it will cause issues in the project. For
example, if technology has to be changed in an organization, and the team members resist
the changes, it will cause a problem with respect to the working of the project.
Mitigation: A successful project is the one that goes with the flow. This means the flexible
project will see long-lasting success in comparison to the projects which resist those
changes.
6. Risks related to the resources: The next project risk example is related to the
resources. This risk arises if the project cannot acquire the relevant resources, for example,
skilled workers, finances, and so on.
Mitigation: A project must show a bright picture to the investors and the team members
related to the project’s success. This way the project can attract more investors to fulfill the
financial aspects and also attract skilled workers to give their best.

20
Interview questions for APM/SCRUM

7. Lack of control over staff priorities: The next project risk example is related to the
staff members. If a project fails to create a backup for team members, then the project will be
delayed, which is indeed a negative aspect that may give rise to other risk factors.

Mitigation: To prevent this risk factor, a project manager must take the initiative to brief out
the importance of the project to the other managers. The manager should schedule the dates
for performing each task and provide backup for every team member. If anyone leaves the
project team, time must not be wasted in finding another candidate suitable for the profile.
Instead, a backup must be kept ready to avoid such risks.
8. Risk factors related to disputes: A project is handled by many people, and it is likely
to happen that disputes can arise due to different thoughts, different, and different
expectations. So therefore, this is included in the project risk examples.
Mitigation: The way to avoid such risks is to conduct meetings regularly and let all the team
members and project-related personnel participate so that the issues can be discussed
openly and a relevant solution is provided as soon as possible.
9. Unplanned work risk: There are several tasks to be performed by each one related to the
project. When tasks are not planned efficiently, then this type of risk arises, and the project
will have cases of delayed work more than the tasks which are being completed.
Mitigation: To avoid this risk, one must attend the project schedule workshops and analyze
the previous projects. You must check all the plans and quantity surveys and document the
findings. This must be reported to the project manager before the project kicks off.
10. Communication issues: One of the other project risk examples includes the
communication channel between the people related to the project. Due to a lack of
communication, there will be no clarity, and instead, confusion will arise which will be
stressful for the efficient running of the project.
Mitigation: To prevent such risks, the communication plan must be established considering
the audience, frequency, and goal of the project. Along with the plan, the right
communication channel is to be established through emails, phone calls, writing, and so on.

53.Differentiate between risk and issues.

Risk can be defined as a condition of uncertainty that may influence a project both in a
positive and a negative manner.
Sometimes risks can be unavoidable, so a Project Manager should always be prepared to
tackle any type of risk. It can influence a project for a longer period of time.
It may ruin a project at once, or it may also make a project successful.
And on the other hand, issues can be defined as an uncertain event that occurs
instantaneously. Risks are the major factors stimulating issues.
However, in comparison to risks, issues are always considered as an event that impacts
negatively do any process or procedure of a project.

54.What strategy do you follow to mitigate the risks involved in a project?

Ans. There will always be risks involved in a project; sometimes even before you start it. You
must be able to give the interviewer enough points on different areas where you can work so
that there are effects of risks.

55.What are the five steps of Risk Management?

The five steps of Risk Management are given below -
Risk Identification: To identify the risks that your company is exposed to in its current
operating environment. There are several types of risks, such as market risks, legal risks,
regulatory risks, environmental risks, etc. It's crucial to be aware of as many risk factors as
possible.
Risk Analysis: Once a risk has been identified, it must be investigated. The scope of the
danger must be determined. It's also important to understand the connection between other
internal factors and risk. It's critical to determine the risk's severity and importance by
examining how it affects the business operations.

21
Interview questions for APM/SCRUM

Ranking the risk: Risks must be ranked and prioritized. Most risk management solutions
include numerous risk categories based on the severity of the danger. Risks that may cause
minor discomfort are prioritized the least, but risks that can result in significant loss are
prioritized the highest.
Treating the risk: As much as possible, all risks should be avoided or reduced by contacting
experts in the field in question. In a manual environment, this would include contacting each
and every stakeholder and setting up meetings for everyone to discuss the issues.
Risk review: To ensure that it has been entirely eradicated, the risk evaluation is done.

56.RISKS
Risk can be defined as a predicament or situation exposed to any small or big danger.
However, as long as we know how to presume and manage risk, we can overcome the snags
to move forward and complete the project without delays. Here are some of the risks involved
in Agile software development and how they can be resolved:
 Budget Risk: When any project is planned, an estimated budget is discussed for it.
One of the foremost risks in the Agile software development process is going over
budget. It is not always possible to presume variations in customers’ needs or even
changes in the market. Hence, going over budget is a very common and potential
risk.

Solution: The best way to ensure that the project sticks to the budget is to avoid
overquoting or underquoting. A reserve should also be maintained to avoid running
out of money in case of necessary changes costing more than planned. Above all this,
there should be a plan in place stating solutions in case the budget issue occurs.
 Scope Creep: Scope creep happens when the scope of the project starts to expand.
Along the way, the customers might want to add features that were not already
discussed at the planning stage. When this happens, it is called scope creep leading to
project going over budget and deadline being pushed.

Solution: Not only is it essential to plan the scope of the project in advance, it is also
necessary to ensure that the plan is being followed. The progress of the project should
be constantly checked by the manager to avoid the risk of scope creep. While
discussing the plan, it should be ensured that the stakeholders agree and sign on the
planned scope. Besides this, the software development team should also implement a
change control process after discussing it with the customer.
 Not sticking to Agile: Agile methodology focuses on collaboration and flexibility.
This means that the self-organizing cross-functional teams, through iterative testing,
are quick to anticipate changes in customer needs corresponding to the dynamic
market and come up with pragmatic solutions along the course. However, if the Agile
process is not followed carefully, the issues won’t be eliminated on time. As a result,
the overall cost will be more when the changes have to be made after the
development process is over. The product quality will also suffer considerably.

Solution: Here, communication is key! Following Agile methodology properly is

important for the software development process to be successful. The stakeholders
must understand the importance of applying Agile principles to the process and how
the results can be heavily impacted if not followed through and through. It should be
carefully communicated and applied.
 Time Delays: Sticking to deadlines for software release and reducing the time-to-
market of the product is the main goal of the whole process. Several factors like
improper planning, mismanagement, lack of talent, continuous change in customer
needs and variations in market dynamics besides budget issues can lead to delay in
the completion of work.

22
Interview questions for APM/SCRUM

Solution: The best way to avoid time delays is to keep room for delay while planning
the timeline. You have to factor in reasons like emergencies, holidays, time taken for
testing and QA and complexities in the project and time taken to incorporate changes
after each round of testing. Even after all this, there should still be some extra time
that can allow further improvement.
 Miscommunication of goals: Agile software development methodology succeeds
because it ensures continuous communication among team members to achieve each
solution or goal. If even one member has misunderstood or miscommunicated a step
of the product lifecycle or ongoing operation, it can collectively affect the outcome.
Solution: To avoid this kind of risk, the best solution is to apply Squad-based agile
software development. This essentially means that an Agile team that is well equipped
and aware of each member’s talent can work with each other closely to deliver the
highest quality product. An Agile squad comes with several benefits that include each
team members being aware of each other’s capacity and knowledge, easier
communication due to same work location, increased development speed because of
continuous discussions, reduced risk due to low chances of miscommunication and
autonomy allowing them to choose the path they want to reach the goal.

57.What strategies do you use to manage risks in an Agile project?

Understanding your risk management approach is essential for employers, as they want to
ensure that you can identify, assess, and mitigate risks that might arise during the project
lifecycle. Agile project management involves constant change and adaptation, so
demonstrating your ability to manage risks effectively within this framework shows that you
can maintain control while still embracing the flexible nature of Agile.
Example: “As an Agile Project Manager, I employ a proactive approach to risk management.
First, during the planning phase, I work closely with the team to identify potential risks and
assess their impact on the project. We then prioritize these risks based on their likelihood and
severity.
To address high-priority risks, we develop mitigation strategies and contingency plans. For
example, if there’s a risk of resource unavailability, we might cross-train team members or
establish backup resources. Additionally, we continuously monitor and reassess risks
throughout the project lifecycle using tools like risk burndown charts and regular risk review
meetings.
This iterative approach to risk management allows us to adapt quickly to changing
circumstances and maintain project momentum while minimizing negative impacts on our
deliverables and overall business goals.”
58.How Do You Ensure You Remain In Control And Professional While Dealing With
Unforeseen Situation In Your Project Team?
While projects must undergo a sufficient risk assessment, it is impossible to recognize all
potential risks. This means that sometimes unforeseen situations can occur, whether through
the project itself or the team. It is a key part of agile project management to have the ability
to adapt to the unforeseen in a quick manner that gets the issue resolved.
It’s a good idea to have an online management tool that allows for live updates so that you
can monitor the projects on the go and address any individuals that could help resolve them.
But overall, it is important to keep a manner that is adaptable and understanding.

59.How Will You Conduct Risk Analyst In A Project As An Agile Project Manager?
As with any form of management, there will always be risks involved when going into a
project. As the agile project manager, it is your responsibility to make sure that all risks are
taken into account, and that any precautions are put into place to limit the risk. In an agile
project, it is a good idea to create a risk burndown chart that identifies the risk alongside the
percentage of it happening and the size of the loss that would occur from it. Make sure to talk

23
Interview questions for APM/SCRUM

to all team members when doing the risk assessment, as they may have a better
understanding of the risks within their subject area. Remember to take into account risks in
the areas of budget, personnel, knowledge, and productivity, along with safety risks.

60.What does the concept of Confidence Vote mean in Scrum? Why is it vital?
The Confidence Vote gets held at the Program Increment Planning session following the risk
analysis. It is when all team members assemble and voice their opinions and vote with their
fingers on their confidence level in completing the PI Targets. The confidence vote can be
used only once all the features and user stories get adequately estimated and prioritized. All
work must be clear to all parties involved, with all dependencies and risks clearly defined.
A vote of confidence can help to create an environment in which people feel comfortable
sharing and expressing their ideas. It boosts team morale because members should feel that
their opinions are valued.

61. What Are Project Dependencies?

Project dependencies, also called task dependencies, are relationships between tasks based
on their sequence. Dependent tasks require one or more other tasks to be completed or
started before the team can start work on them.

62.The Importance of Project Dependencies

Project dependencies are a key part of project planning. Having a clear sequence of tasks
helps ensure that teams complete work correctly and efficiently. Stay organized, avoid
delays, and manage complex projects by identifying dependencies.

63. Types of Project Dependencies

There are four main types of project or task dependencies. Each outlines when a task can
start or finish based on the status of another task. Some tasks might be dependent on more
than one previous task.

 Finish to Start: In this scenario, task A must finish before task B can begin. This is
the most common example of a project dependency and is generally the most
straightforward. For example, a fabrication team cannot begin building until the final
design has been approved.
 Start to Finish: In a start-to-finish dependency, task A cannot finish until task B has
started. These are less common but are prevalent in retail and shift work
environments. For example, the morning shift in a restaurant’s kitchen cannot finish
their day until the evening shift has arrived and started their own.
 Start to Start: Start-to-start dependencies require task A to start before task B can
begin. For example, a writer cannot begin to revise an article draft until the editor has
started to edit it.
 Finish to Finish: In a finish-to-finish scenario, task B cannot finish until task A has
finished. Start-to-start and finish-to-finish dependencies are often related to one
another. For example, a server cannot finish serving everyone at a table until the
kitchen has finished cooking and plating each dish that was ordered.
64.Key Dependencies in Project Management
There are five key dependencies in project management. The four internal dependencies are
based on logic, resources, preferences and best practices, and cross-team dependencies. In
addition, some dependencies come from external sources.

These are the key dependencies in project management:

 Logical: Logical dependencies follow a logic-based binary, such as an if-then

statement. Some tasks must be completed before it is possible to complete other
tasks. Logical dependencies follow a predictable path from start to finish.

24
Interview questions for APM/SCRUM

 Resource-Based: Resource-based dependencies deal with available resources rather

than task completion. Resource dependencies can be focused on the availability of
labor, financing, materials, or software and upgrades.
 Preferential: Preferential dependencies refer to best practices for the completion of a
task. These dependencies suggest that it is best to let the glue dry or the data mature
before moving on to the next task in the sequence.
 Cross-Team: Cross-team dependencies relate to deliverables and tasks completed by
other teams. For example, the sales team must wait for the engineering team to
complete a new software product before they can start offering it to customers.
 External: External dependencies refer to any circumstances outside the business’s
control, such as weather events, bureaucracy, or legislature.
65.What is a blocker

A blocker is any event or circumstance that can hinder the completion of a project task, such
as team member absences or shipping delays. Note that most tasks have some combination
of both internal and external dependencies of varying impact.

66.Internal Dependencies in Project Management

Internal dependencies in project management include logical, resource-based, preferential,
and cross-team dependencies. We’ve listed more subcategories below and provided
examples of each.

These are some common internal dependencies:

 Task Based: Basic, task-based dependencies follow a logical path to completion. For
example, you must print shipping labels before you can mail customer orders.
 Team Based: Team-based dependencies require collaboration between teams. For
example, you can’t take product photos for sales brochures until the production team
produces a prototype to photograph.
 Approval Based: Some dependencies are based on approval requirements. For
example, you can’t purchase new large-scale manufacturing equipment until you get
approval from the CFO.
 Best Practices Based: Many dependencies are based on the best practices required
to complete a task. For example, it is best to let your kitchen equipment cool down
completely before cleaning it.
 Resource Based: Resource-based dependencies require certain items to be available
for use before a task can begin. For example, you cannot print sales brochures without
the right kinds of cardstock and ink.
 Software Based: Some dependencies require software inputs or updates before
tasks can progress. For example, you must update storage software regularly for
continued secure access to data.
67.External Dependencies in Project Management
External dependencies are outside of a business’s control. They can be the most difficult to
predict and manage. These include factors such as deliveries, weather events, finances, and
traffic changes.

These are some common external dependencies:

 Deliveries: Supply chain issues can affect project timelines. You can’t start the work
to build a product if the materials haven’t arrived.
 Weather: Good weather is a requirement for many construction-related tasks. You
cannot begin construction on a house while there is a hurricane.

25
Interview questions for APM/SCRUM

 Bureaucracy: Most industries require various certifications and permits, which are
dependent on local bureaucracy. Oftentimes work cannot begin before the team
secures those permits and certifications.
 Traffic: Traffic congestion can delay some work. For example, you cannot set up your
booth at a trade show when all of your equipment is stuck in a traffic jam.
 Finances: A company’s finances, especially regarding loans, can cause delays due to
dependencies. You cannot start purchasing expensive equipment when your loan
funding hasn’t come through.
 Legislature: Some dependencies are based on anticipated legal changes. For
example, a restaurant in a dry county might have plans to start offering wine if the
ordinance changes.
68.How to Manage Project Dependencies
The best way to manage project dependencies is to learn how to identify them. Staying
organized and having strong communication with your team will help as well. We’ve outlined
these and other best practices for managing project dependencies below.

Here are some best practices for managing project dependencies:

 Learn to Identify Dependencies: The first step to successfully managing project

dependencies is learning to identify them. “Pay attention to anything that could
impact the timeline or cost of your project. This includes both dependencies and
internal constraints such as team size or budget. Then, make a list of all the potential
dependencies so you can keep track of them throughout the project,” suggests
Larson.
 Stay Organized and Updated: Keeping your project information up to date will help
you spot dependencies early on. It can also help you identify ones you may have
missed. “Generally speaking, it's best to identify dependencies and constraints as
early as possible. The trick is making sure you routinely keep an eye out for new and
missed dependencies. This can be more easily done via weekly status meetings with
your team, or by consistently asking about them throughout the project,” says Beran.
 Identify and Track Risks: Create a risk log, and use it to keep track of risks as your
project advances. Risks are often linked to constraints and dependencies, so it can be
valuable to keep an eye on them as part of your general risk management strategy.
 Make Contingency Plans: Allocate extra time into your schedule and money into
your budget. Some dependencies are entirely out of your control, and something as
simple as a missed delivery window might derail your schedule. It is always a good
idea to have a backup plan.
 Communicate with Your Team: Communicating the status of deadlines and
deliverables is crucial to managing expectations surrounding dependencies. “Project
dependencies are managed poorly when there’s a lack of communication between
teams and departments in a business. When clear goals and time frames aren’t set for
each project and it isn’t clear how each task depends on the other, processes aren’t
managed effectively,” explains Fichtner.
 Use Software: Many project management software programs include tools to help
track and manage project dependencies.

69.Project Dependency Management Tools

 Project managers use various tools to track and manage project dependencies.
Choose the tool that fits your organizational style and the needs of your team. Kanban
boards, Gantt charts, calendars, and project management software are all useful.
 Kanban Boards: Kanban boards are tools that help you create visual workflows for
project tasks and phases. They can be made digitally using software or physically on a
wall or whiteboard. Use a Kanban board to break down a project into its component
parts and more easily identify dependent tasks.
 Gantt Charts: A Gantt chart is a horizontal bar chart that acts as a visual scheduling
tool. Each bar represents the time it takes to complete a project task or phase. The

26
Interview questions for APM/SCRUM

vertical structure of these bars indicates when one task ends and another begins.
Gantt charts can help a team identify and visualize task dependencies.
 Shared Calendars: A lower-tech solution to dependency monitoring is the use of
shared calendars. Project managers can use shared calendars to indicate start and
end dates for project tasks. This is a great option for tracking scheduling
dependencies, but it is much harder to use calendars to track resource-based or
external dependencies.
 Project Management Software: Project management software can combine these
tools into a single solution, using their best elements to create a powerful project
planning and dependency tracking tool. Many let you visualize your dependencies in
multiple ways, which can be helpful for identifying those that may not be immediately
obvious.
70.What is assumptions?
Assumptions in RAID refer to items that you are relying on, but that may not be true123.
Assumptions are aspects of the environment or surroundings to your project that you believe
will be in a certain state1. The purpose of tracking assumptions is to be prepared for your
assumptions being wrong1. Assumptions are anything deemed to be in place that will
contribute to the successful result of your initiative2. The log includes details of the
assumption and validation2.

71.What does DoD mean?

Definition of Done (DoD) refers to the collection of deliverables, which includes written codes,
comments on coding, unit tests, integration testing, design documents, release notes, etc.
This adds verifiable and demonstrable values to project development. DoD is very helpful to
scrum while identifying the deliverables to achieve the objective of the projects

It helps with:

 Defining the steps required to deliver the iteration

 The usage of appropriate tools like burndown to make the process more effective
 Ensuring on-time feedback throughout the project life cycle
 Ensuring the walkthrough of the product backlog items are done and understood
correctly
 The creation of a checklist for the product backlog items
 Ensuring the DoD is defined to become task-oriented
 Involving the product owner for reviewing during the sprint and sprint retrospective

72.Mention the challenges involved in developing Agile Software?

The significant difficulties encountered when creating Agile Software include:
 more customer interaction and testing
 management is more affected than developers
 More preparation is needed.

73.Challenges faced by AGILE Manager

Challenges in Agile Project Management
12 common project management challenges
Project management is a multifaceted process that encompasses multiple phases—initiation,
planning, execution, monitoring and Controlling, Closing.

1. Scope creep
Scope creep occurs when a project's scope grows beyond its original definition or goals. It
typically happens when stakeholders ask for changes to the project. Any alteration to a

27
Interview questions for APM/SCRUM

project's plan can cause confusion, increase the cost of resources and make it difficult to
meet deadlines.
If you can avoid scope creep, you can improve your chances of completing a project on time
and within budget. To prevent or manage scope creep, consider the following strategies:
 Clearly define project requirements and goals.
 Create a schedule that includes every step of the process.
 Involve clients or stakeholders in project planning.
 Use tools such as Gantt charts to plan and track projects.
 Communicate to stakeholders how scope changes might affect deadlines and
budgets.
 Refuse project changes that might cause delays or unreasonable costs.

To manage scope creep, we need to use the change control mechanism to keep it under
control. This includes the following -
 Maintaining a baseline scope and keeping track of the project's progress.
 To evaluate actual work performance metrics to the baseline scope, i.e., "How
different is the current project from the original plan?", we need to perform Variance
analysis.
 Identifying the severity and source of the observed alterations.
 Selecting whether to take preventive or corrective action in response to requests
regarding changes.
 To recommend actions and manage all change requests by using the Perform
Integrated Change Control method (whether preventive or corrective).

2. Poor communication
Strong communication is one of the keys to completing a project successfully. With well-
developed written and verbal communication skills, a project manager can effectively give
instructions, gather information and update stakeholders. Otherwise, their team can become
confused, leading to delays.
Improve communication between all of the parties involved in a project by:
 Using collaborative tools and project management software to update team members
 Giving frequent feedback concerning employee performance
 Developing a communication plan and status report schedule for stakeholders
 Doing team-building activities to improve relationships and communication between
team members
 Being transparent about project progress
 Keep in mind that it may be necessary to adjust your communication methods to
accommodate different communication styles

3. Unclear goals
Projects can be successful only if the team has well-defined and measurable goals to work
toward. Ideally, every member of the team is aware of each project objective and the
stakeholders' exact expectations concerning each. Otherwise, they may spend undue time
and resources trying to accomplish something that doesn't provide the desired value.

Devise and communicate clear project goals by:

 Using the SMART method to set goals

 Determining the project's specifications, including the timeline, before
implementation
 Meeting with your team to define and discuss the goals
 Using project planning software to specify goals and each team member's role in
achieving them
 Identifying ways to monitor progress, such as with milestones

4. Poor budgeting

28
Interview questions for APM/SCRUM

Smart financial planning and skillful cost management are essential for ensuring that you use
funding appropriately. In contrast, poor budgeting may result in undesirable outcomes.
Without a strong handle on money matters, you may find your team facing cost overruns,
which is likely to displease the stakeholders and prevent the successful completion of the
project.

Take these steps to avoid budgeting issues:

 Plan your budget ahead of time, using realistic estimates.

 Review similar projects to compare their budgets to yours.
 Get advice from experts, such as software developers or quality assurance specialists,
who are familiar with cost and time estimates for your type of project.
 Reassign resources or change suppliers, services or vendors as needed.

5. Skill gaps
You may find that the skill levels of some of your team members aren't enough to satisfy the
required competencies to realize project goals. This situation is known as a skill gap. If
someone is incapable of performing the duties of their role, then you can expect a
corresponding gap between your project goals and project outcomes.

Ensure your team members have adequate skills for your project by:
 Creating a list of the skills or knowledge a project requires
 Assessing current employee skills and providing training as needed
 Assigning employees to project tasks based on their strengths and experience
 Outsourcing or hiring additional staff to complete specialized tasks

6. Insufficient risk analysis

Risk analysis is the process of predicting the potential factors that may arise that can
jeopardize the success of a project. It's a vital part of the project life cycle, but the process
itself is susceptible to certain risks. Rushing the analysis, for example, can lead to oversights
that fail to foresee major obstacles. This, in turn, can result in flaws in the project plan,
financial issues or unknown variables.
Improve your risk analysis by:
 Researching the possible issues a project or the team might encounter during every
stage of the project
 Developing control measures to prevent potential risks
 Creating replacement plans you can use if the project changes
 Knowing what resources you have to minimize or control risks

7. Lack of accountability
Accountability means taking ownership of actions and their outcomes, particularly when it
comes to mistakes. Thus, an accountable person is willing to face the consequences of what
they've done and make every effort to resolve the subsequent issues that have arisen. When
leaders and team members lack accountability, they can impede progress in a couple of
ways. One is by damaging the morale of the team, which may absorb the consequences of a
particular person's mistakes. The other is by slowing productivity when project resources
channel into the effort to identify the cause of a problem.
Improve your team's accountability on a project by:
 Assigning every team member clear tasks
 Establishing a common goal and helping your team work toward it
 Building accountability into the project's workflow so team members understand their
roles and responsibilities
 Leading by example so that your team members understand it's acceptable to make
mistakes as long as they take responsibility for them
 Building trust between the members of the team so everyone feels comfortable being
honest with one another

29
Interview questions for APM/SCRUM

8. Stakeholder disengagement
Stakeholder engagement is the process by which a project's stakeholders—those who have a
vested interest in the project, such as the client—collaborate and communicate with the
team.
The involvement of the stakeholders is important because they can provide input that guides
the project toward the best possible outcome. Several of the other challenges that projects
face, such as unclear goals and insufficient risk analysis, arise when the stakeholders aren't
sufficiently engaged.
Follow these steps to ensure stakeholder engagement:
 Involve stakeholders in the project planning process.
 Communicate with stakeholders frequently, and give them regular project updates.
 Directly ask clients for their feedback on every project phase.

9. Unrealistic deadlines
An unrealistic deadline is a project due date that is impossible or unreasonable to meet given
the specifications and requirements. When a team faces unrealistic deadlines, they find
themselves forced to condense their activities in such a way that compromises the quality of
their work. As a result, the finished state of the project is likely to fall short of client
expectations.
Make sure you set realistic deadlines by:
 Prioritizing tasks
 Building extra time into your deadline to account for potential obstacles
 Finalizing deadlines with relevant team members
 Discussing deadline concerns with stakeholders before starting the project
 Using a project calendar to plan and manage schedules and deadlines

10. Technological shortcomings

Nowadays, project management software is essential for planning, organizing and managing
project progress. It's not uncommon for project teams to encounter issues with the software
and other tech tools they've chosen to help manage the project life cycle. Being forced to use
insufficient technology, they may encounter delays arising from frustration, slowed
communication and the additional learning required to devise workarounds.

Avoid or address technological shortcomings by choosing an effective program that meets

specific needs, such as:
 Tracking time
 Functionality on multiple devices
 Customization
 Integration with existing tools and software
 Team communication channels
 Scheduling
 Searchability
 Notifications
 Easy to use
 Prioritize the features you value most, and find a project management program that
not only includes those features but also fits your budget.

11. Scheduling conflicts

A scheduling conflict is a situation in which two or more priorities compete for your time and
attention. If your team or company is working on multiple projects at once, you might
experience scheduling conflicts. As a result, one or several projects may face delays and
difficulties concerning resource allocation.
Share project resources effectively and keep your project on schedule by:
 Coordinating your project schedule and needs with other project managers

30
Interview questions for APM/SCRUM

 Checking team members' vacation and time-off schedules to avoid unexpected

absences
 Using an online calendar planner to organize multiple projects and their resources
simultaneously

12. Uncertainty
Uncertainty is a condition in which stakeholders, including the members of the team, are
unsure about any aspect of the project on which they're working. They may feel unconfident
about the team's ability to meet goals, the potential impact of the project when completed or
the use of resources associated with the project. When uncertainty arises, it can affect the
morale of everyone involved, which can lead to poor project outcomes.
Reduce uncertainty by monitoring progress and tracking metrics, such as:
 Burn rate, or how quickly you are spending your budgeted resources
 Estimated hours and costs versus actual hours and costs
 Employee workload to ensure each team member has a balanced number of tasks

74.Difference between bug and defect

BUG DEFECT

A bug is a problem in the software A defect is a deviation from the

that causes it to behave expected behaviour or requirement
DEFINITION unexpectedly or incorrectly. of the software.

Bugs are often associated with

issues in the code, such as logical Defects are typically related to
errors, syntax mistakes, or runtime problems in the software design,
ORIGIN problems. requirements, or functionality.

Bugs may or may not be Defects are usually easier to detect

immediately apparent and can because they result from a clear
DETECTABILITY sometimes be challenging to detect. deviation from specifications.

Bug fixing is generally the Identifying and reporting defects is

RESPONSIBILIT responsibility of the development often the responsibility of quality
Y team, and including programmers. assurance or testing teams.

Bugs can vary in severity, from Defects are usually considered

minor inconveniences to critical serious, as they represent non-
issues that cause the software to compliance with the software's
SEVERITY crash. requirements.

Bugs can be present at any stage of

development but are more common Defects are often discovered
LIFECYCLE in the coding and implementation during the testing phase or after
STAGE phases. the software has been released.

Defect resolution may involve

Bug fixing usually involves changing requirements, design, or
modifying the code to correct the functionality to align with the
FIXING issue or improve its functionality. expected behaviour.

31
 Interview questions for APM/SCRUM

75.Difference between lean & agile

Lean Agile DevOps

Primary focus Enhancement of
Elimination of process Iterative development collaboration between Dev
waste with feedback loops teams and IT Ops
Improvement of
Quick response to deployment frequency and
Continuous improvement changes software quality
Best suited Manufacturing
for
Service industries Software development Software development
Tools and Value stream mapping Scrum boards CI/CD pipelines
techniques
Root cause analysis (RCA) Sprints Infrastructure as code (IaC)
Configuration management
5S Daily Stand-ups tools
User stories
Kanban boards
Implementati Resistance from employees Requires cultural shift Integrating diverse and
on challenges toward collaboration complex tools into a
cohesive workflow
Complex to implement Entails frequent changes Overcoming team silos
across multiple teams

32
Interview questions for APM/SCRUM

76.SAFe principles

77.SAFe stands for – Scaled Agile Framework

78.Fibonacci series
Sequence of numbers • Used for estimating story sizes • Each number is the sum of the two
preceding numbers • 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on

79. How to deal with Scope Creep?

Scope creep refers to a change that’s uncontrolled and added without checking its impact on
scope, time, cost, etc.
To handle it, here’s what needs to be done:
 Close monitoring of work being done on a day-to-day basis.
 Understanding and communicating the vision to the team and ensuring they’re
aligned.
 Capturing, reviewing the project requirements regularly (against what is delivered), to
emphasize to the team & customer about the requirements signed off.
 Ensuring that any changes introduced go through change control & are implemented
based on the approval for change request.
 Avoid gold plating.

33
Interview questions for APM/SCRUM

80.How do you handle scope creep in an Agile project?

Scope creep can be a significant challenge in any project, and Agile methodologies are no
exception. By asking this question, interviewers want to gauge your ability to manage
changing requirements, maintain control over the project, and ensure that new features or
tasks don’t compromise the project’s overall success. They’re looking for your understanding
of Agile principles, proactive planning, and communication skills when it comes to managing
stakeholder expectations and team focus.

Example: “To handle scope creep in an Agile project, I first emphasize the importance of
clear communication and collaboration with stakeholders. This involves setting expectations
upfront about the project’s goals, priorities, and potential risks associated with scope
changes. During sprint planning meetings, I encourage open discussions to ensure that all
team members understand the requirements and can voice any concerns.

When scope creep does occur, I address it by evaluating its impact on the project timeline,
resources, and overall objectives. If the change is deemed necessary and beneficial, I work
with the team to adjust the backlog and reprioritize tasks accordingly. However, if the change
could negatively affect the project, I communicate this to stakeholders and propose
alternative solutions or discuss postponing the change for a future iteration. This approach
allows us to maintain focus on delivering value while remaining adaptable to evolving
needs.”

81. What are the Kanban principles and practice?

The Kanban method is derived from the lean production system developed at Toyota.
Kan=Card. Ban=Signal/board
It is a visual system to monitor work.

5 principles of Kanban
 Visualize the workflow: knowledge work projects, by definition, manipulate knowledge,
which is intangible and invisible. Therefore, having some way to visualize workflow is very
important in organizing, optimizing, and tracking.
 Limit WIP: Restricting the amount of work in progress improves productivity, increase
visibility of issues and bottlenecks and continuous improvement.
 Manage Flow : By tracking the flow of work through system, issues can be identified and
changes can be measured for effectiveness
 Make process policies explicit: it is important to clearly explain how things work so the
team can have open discussions about improvements is an objective, rather than
emotional or subjective way
 Improve collaboration: Through scientific measurement and experimentation team
should collectively own and improves the processes it uses.

82.What are ceremonies in kanban

1. DAILY STAND-UP MEETING

These are held daily and typically last for 15 minutes per session. The purpose of these
meetings is to answer the following questions:

 How is work flowing?

 Is something impeding us?
 How can we improve?

2. REPLENISHMENT MEETING
Replenishment meetings are held weekly for an average of 30 minutes per session. The
purpose of these meetings is to single out the backlogs in the Kanban board. The whole idea

34
Interview questions for APM/SCRUM

is to ensure that there is a seamless flow of tasks and no backlogs that can drag the team
down on its way to progress.

A backlog management solution is discussed along with a quick check on small or large tasks
that need to be replenished.

3. SERVICE DELIVERY
This type of Kanban meeting is held twice a week for 30 minutes each session. The sole
purpose of this meeting is to check with the team’s progress and to ensure client satisfaction
in the delivery of the team output. There is also an added layer of benefit to this: it builds
customer trust by directly addressing their concerns.

For this reason, this meeting typically involves the customer (client) and some
representatives of the service delivery team. These meetings are also a great opportunity to
assess if team targets are met.

4. DELIVERY PLANNING
This meeting is held per delivery cadence and takes roughly 1 to 2 hours per session. Not all
tasks or output can be delivered to the client immediately upon completion, hence, this
meeting is conducted in order to do final checks before the team output is delivered to the
client. Setting a realistic and achievable delivery date is a crucial part of this planning
process.

5. RISK REVIEW
The Risk Review is held monthly for 1-2 hours per session. As the name implies, the purpose
of this meeting is to assess and mitigate risks within an organization that can impede delivery
of work output or completion of projects within the designated delivery date. Past and
present failures must be evaluated to plan for the future as well.

6. OPERATIONS REVIEW
This is also held monthly for at least 2 hours per session. It specifically looks into the
operations and processes in place that can slow the team down, inhibiting its ability to meet
delivery dates. By looking at the big picture, it allows the team to analyze the current
workflow to figure out where improvements can be made.

7. STRATEGY REVIEW
This Kanban meeting can be conducted quarterly and typically lasts for half a day. It is one of
the most important Kanban ceremonies because it looks at your project management as a
whole. It is the perfect opportunity to review current strategies and the accompanying
results. If team targets are not met, actionable insights and strategies must be devised to
ensure that the goals are satisfied.

83.What are the main Kanban metrics?

KPI metrics are the lifeblood of any Agile project management strategy, and when it comes to
Kanban, four key metrics can make or break your workflow.

Lead time

Lead time measures the time from when you add a new software development task to
the Kanban board to the point where the team marks the task as complete. In essence, it
gauges the total time a task takes to travel through the entire Kanban workflow.
This metric is pivotal for project managers because it offers a comprehensive view of how
long tasks take within the system, allowing for more precise planning and effective resource
allocation.

35
Interview questions for APM/SCRUM

Cycle time

Cycle time zooms in on the “active work" phase of the Kanban system, measuring the time
between when a team member starts a task and when they complete it. It doesn’t matter if
nobody started the task until months after creation; cycle time only starts when the task
moves into the active workflow.
Cycle time can indicate whether your team is working efficiently or if you need to make any
adjustments in the active phases of tasks.

Work-in-progress

Work-in-progress represents the number of tasks currently in the "active" or "in-progress"

stages within the Kanban system. It measures the volume of ongoing work at any given time,
providing a snapshot of tasks that are neither in the backlog nor complete.
Monitoring work-in-progress is crucial because it helps to balance the team's workload and
identify bottlenecks—ideally, your team is working but not multitasking.

Throughput

Throughput quantifies the number of tasks or work items your team successfully completes
within a specific time frame, such as a day or a week. It measures the team's output or
productivity over that period.
This metric is essential because it directly indicates your team's productivity levels, allowing
you to make informed decisions for future task assignments and project timelines.

84.How are these metrics measured?

But if you're looking for a one-stop solution for measuring these metrics, Jira has you covered.
Jira doesn’t just help you track metrics effortlessly—it also provides actionable insights that
aid in continuous delivery. There’s a Jira Kanban board for every Agile and DevOps software
development team.

Control charts

A control chart is a graphical representation and diagnostic tool that offers insights into your
workflow's stability and variability. The chart plots cycle time data points over a period,
showing the average time it takes to complete a task and the variability around that average.
This is valuable because high variability often signals instability in the process.

When you dig into a control chart, you interpret the story behind the data points. Here are
some possible interpretations:

 A widening gap between the chart's upper and lower control limits may indicate
increasing unpredictability in cycle times.

 A clustering of points far from the average line could signal a bottleneck where tasks
are getting stuck.

By scrutinizing these patterns, you can proactively identify issues and implement changes,
making your Kanban system more efficient and responsive.

Cumulative flow diagrams

A cumulative flow diagram is another visual tool in the Kanban toolkit. Unlike control charts,
which zero in on cycle time, a cumulative flow diagram provides a layered view of all four
important Kanban metrics simultaneously. The diagram consists of multiple colored bands,
each representing a different stage of your workflow, stacked over time.

36
Interview questions for APM/SCRUM

A cumulative flow diagram allows you to see the flow of tasks across various stages in real
time. The changing width of each layer can offer immediate insights. Consider the work-in-
progress layer:

 If the work-in-progress layer starts to expand, it's a red flag that tasks are
accumulating, and you may have a bottleneck.

 If the layer narrows, it suggests that tasks are moving through more quickly than new
ones are coming in, signaling that your team might have some extra bandwidth.

The ability to see these metrics interact in one place makes the cumulative flow diagram a
powerful tool for timely decision-making and workflow adjustments.

85.The importance of Kanban metrics

Kanban metrics aren't just numbers or data points—they're the pulse of your project's health
and efficiency. These metrics serve as a navigational tool to help you make informed
decisions about things such as allocating resources and setting deadlines.

Spot bottlenecks quickly

If your team’s cycle times are suddenly stretching out and your throughput is dwindling,
they’ve likely hit a bottleneck. These trends are red flags that a particular stage in your
process may be slowing everything down.

Bottlenecks can lead to delayed deliveries, increased costs, and stressed team members. By
spotting these early, you can immediately reallocate resources or streamline the problematic
stage, improving the efficiency and effectiveness of your entire workflow.

Improve forecasting

When it comes to project management, the ability to forecast accurately is like having a
crystal ball. This highly valued skill helps with resource allocation, client expectations, and
timely deliveries—all crucial for maintaining a competitive edge.

Metrics such as lead and cycle times can be your best allies in this. By monitoring these, you
can gauge how long it will take to deliver a task from start to finish. This helps set realistic
deadlines and expectations for your team and stakeholders. Similarly, monitoring throughput
provides a snapshot of your team's efficiency so you can adjust forecasts as necessary.

Maximize efficiency across projects

The real magic happens when you start using these Kanban metrics together. You can gauge
task duration by monitoring lead time and cycle time, while watching work-in-progress
prevents team overload. Adding throughput provides a complete view of your team's capacity
over time.

When integrating these metrics into your daily management practices, you're not just putting
out fires or fixing bottlenecks—you're refining your entire process for future projects. This
proactive approach allows you to continuously improve, adapt, and, most importantly, deliver
more value in less time.

37
Interview questions for APM/SCRUM

86.How to implement Kanban tracking and reporting

If you're looking to implement Kanban tracking and reporting easily and seamlessly, then
specialized software is your best ally. Among the top choices is Jira, a platform that's
practically synonymous with Agile project management.
Jira makes it easy to identify trends, follow the status of every team's projects, and predict
future performance with dozens of pre-configured agile reports. Insights in the backlog and
board empower teams to build and train muscles to continuously learn and improve their way
of working. And if you're just starting out, Jira's Kanban board template makes it incredibly
easy to get up and running.

87.What is Lean project management?

Lean project management eliminates waste in product development, significantly speeding
up delivery.

The goal: catch problems before they cause severe damage. Doing so lets you make
necessary adjustments to prevent project stalls.

Much like the Waterfall methodology, Lean is a structured process that organizes tasks and
allows oversight. Instead of 5 common stages, Lean has 5 core principles.

88.What are the 5 Lean principles?

Lean revolves around 5 key principles: defining value, plotting the value stream, creating
flow, adhering to a pull system, and staying in a state of continuous improvement.

Let's break down the Lean manufacturing principles, where the customer's value will be your
barometer:

1. Define a value: Which activities are time wasters? Which ones add value to the
project? That's the distinction you must make here. Consider your customers. Does
your effort provide value to them, whether directly or indirectly? “A trick when trying
to identify value is to focus on eliminating wasteful activities,” says Atlassian’s Modern
Work Coach Mark Cruth. “Look at the seven forms of waste and try to eliminate them
from your process: waiting, transporting, processing, inventory, motion,
defects/rework, and overproduction.”
2. Map the value stream: The second principle requires a visualization of your
customer value activities. This lets you keep the project on task and moving forward,
especially if you use an Agile project management style, such as scrum. You can use
a Kanban board, such as the one offered in Jira Software, for this.
3. Create a flow: You want your project to flow seamlessly. Any blockage can be
detrimental. Keep an eye out for any potential clots. If one occurs, analyze what
caused it and how to avoid it. For example, clots tend to form while awaiting
stakeholder feedback. Prevent this by limiting the chunks of work for review.
4. Establish pull: Shoving new work on your team when they're at capacity can hinder
flow. Start new work only when there's demand and your team has time. A pull system
creates a work queue, meaning a team member without current work can pull the first
high-priority ticket to focus on.
5. Seek perfection: Continuous improvement is the foundation of Lean project
management. You and your team should be better than you were yesterday. Analyze
performance and identify opportunities for improvement. Remember, you want to
ensure you're providing customer value. If something isn't working, examine why and
make incremental changes based on that. KPI metrics are great to help you gauge
Lean performance.

38
Interview questions for APM/SCRUM

89.What is DevOps?
“Many methodologies and models can trace their roots back to Lean, which is why you will
find the principles of Lean laced into every modern way of working” explains Cruth.

DevOps, for example, is the combination of practices, tools, and cultural philosophies
designed to deliver more customer value quickly by breaking down the wall between
development and operations teams.

Under the DevOps model, developers are no longer siloed and participate in the entire
software development lifecycle. This cross-functional approach helps teams accelerate time
to market, ensure quality of delivery, and operate processes at scale. DevOps also works well
with other methods, so there's no need to choose between DevOps and Agile.
A DevOps team will use every tool in that box, from automated processes to tech stacks, to
deliver results faster and more efficiently. With Open DevOps in Jira, developers can connect
170+ add-ons and third-party integrations to support all parts of the development process
including planning, building, continuous integration, deployment, operations, feedback
collection, and real-time communication.
90.DevOps vs. Lean principles
So, which one should you choose, Lean or DevOps? Let's compare the two.
 Customer orientation: Both methods give importance to the customer. In Lean, you
choose the customer value activities that matter. DevOps creates customer empathy
image mapping, which breaks down business goals into something meaningful for the
client.
 Focus: Lean principles seek to optimize across the entire project. DevOps wants to
integrate development and operations through cross-collaboration and
documentation.
 Execution vs. vision: Lean is all about improving execution for a better result, but
DevOps has loftier goals. It leverages cross-functional teams and automation to effect
systemic changes in a company.
 Automation: DevOps is all about automation. Lean isn't. With automation, DevOps
employs tech to check and deploy code, run tests, and pull requests. That way,
someone on your team won’t need to do this manually.
 Timelines: Lean timelines center around sprints, which could stretch into months.
DevOps sometimes requires delivery on an hourly basis.
If you want a deeper dive into DevOps, we've created a beginner's guide to DevOps to help.
91.Incorporate Lean principles for project management
When it comes to choosing which methodology to use, consider how it affects your
customers. Which method serves them best, a Lean approach or DevOps? Ultimately, it's all
about the value you bring to them.

Whichever works best for delivering customer value, Atlassian's Jira Software can support
you. It's adaptable to both Lean principles and DevOps.
Jira Software tracks projects and keeps your team aligned. They'll have visibility into your
project's workload and progress. Teams collaborate across DevOps to QA for continuous
integration, delivery, and deployment, and that accelerates your team's ability to deliver on
schedule.

92.Is DevOps or Lean better for project management?

If you’re looking to accelerate your team’s ability to deliver, DevOps would be your choice for
project management. That’s because it

 Breaks down silos: Teams work collaboratively throughout the process.

 Creates feedback loops: Continuous feedback from the team and users helps
improve deliverables.

39
Interview questions for APM/SCRUM

 Automates mundane work: Automating tasks such as code deployment and pull
requests frees up your team to focus on more important aspects of a project.
DevOps works well for software development. If you're building a digital product, this would
be the better choice. This is because of the emphasis on cross-team collaboration. In
comparison, Lean focuses mostly on process improvements.

Use Open DevOps, powered by Jira Software, to keep your team shipping and operating high
customer-value software.
93.What are the benefits of implementing Lean principles?
Lean principles allow your team to become a Lean, mean fighting machine. It does this
through increased efficiency and improved team collaboration. You'll be able to mitigate risk
and avoid bottlenecks. That protects the bottom line.

Lean principles will keep your team in a growth mindset through continuous improvement,
helping them adapt faster and stay engaged.

But what is the main benefit of implementing Lean principles? A more loyal and satisfied
customer base.

94.What are some common challenges of Lean implementation?

While Lean can be great for project management, it has a few challenges, which include

 Lack of support: An unsupportive manager can ruin Lean activities. They become
the keepers of all project information, so you must go through them to complete the
work.
 Solution: Understand that change is hard for some. Have empathy and treat
managers with respect to earn their trust. Show them the workflow gaps and
how Lean mitigates them.
 Improper training: Teams won't succeed when you thrust Lean on them without
training. They'll flounder, causing even more bottlenecks.
 Solution: Onboard your team through proper training in Lean principles.
Create a “best practices” document for the team. Set expectations with the
team before embarking on a Lean project. Provide a feedback loop.
 Unrealistic expectations: Expecting your team to do more than they're capable of
can also be a detriment.
 Solution: Set realistic deadlines and goals. Review them with your team
before, during, and after the project. Keep track of them weekly.
 Overemphasis on tools. Tools are great, but they're better when used by people.
Yet some Lean companies focus on tools rather than team culture.
 Solution: Be transparent and build a culture of trust. Lean's philosophy of
continuous improvement can help show your investment in the team's growth.

95.What are the 5 levels of agile planning

 Vision
 Roadmap (2-3) years
 Release (2-3) months
 Iteration 2-4 weeks
 DSM

96.Attitudinal Traits - EEPIF

 Energetic
 Empathetic
 Proactive

40
Interview questions for APM/SCRUM

 Inquisitive
 Friendly

97.Requirement Techniques
 Interviewing – open ended questions
 Prototyping – Wireframes/mockups
 Story writing workshops – Brainstorming, Nominal group technique, ideal mind
mapping
 Questionnaires
 Role based requirement Identification – Agile personas, proxies, consider
regulatory/compliance

SAFe Interview Questions And Answers

98.Explain Agile and some of its related frameworks.

Agile is simply 4 values and 12 principles to deliver value incrementally and iteratively. It is

neither a framework nor a methodology. It was derived to provide software incrementally

with high quality. Scrum and SAFe are the two frameworks that follow Agile. Scrum is all

about the team and SAFe is for scaling agility.

99. What do you know about the levels of SAFe?

There are three levels of the latest version of SAFe, as follows:

1. Essential SAFe

2. Large Solution SAFe

3. Portfolio SAFe and

Essential SAFe is a mandatory level in SAFe, which is for a single program (we call it Agile

Release Train) of 50 to 125 people. The other 2 levels are optional.

When there are more than 125 people and more complex, for ex., 300 people working for 1

product/solution, we need Large Solution SAFe.

Portfolio SAFe can be implemented when the entire portfolio wants to move to SAFe, which

means, multiple programs / ARTs within the portfolio including the Portfolio leadership want

to follow SAFe.

41
Interview questions for APM/SCRUM

100. Explain the metrics in SAFe.

Metrics by definition are agreed-upon measurements that help evaluate the progress of the

organization. There are measurements in SAFe as well. They help measure the performance

of the team, ART, Value Stream, and Portfolio based on the metrics collected. Let’s look at

various metrics that help SAFe organization measure and improve.

Team Metrics

Every Agile team in SAFe ART measures metrics that are critical for the team. Here are a few

key metrics that Agile teams measure

 Velocity – Average story points delivered per iteration

 Predictability in every iteration (story points committed vs. delivered per iteration)

 % Unit test automated – % Code coverage through unit test automation

 Number of open defects – Number of open defects at any point in time

ART Metrics

Flow-based metrics are key metrics that help ART measure and improve. Here are a few

Flow-based metrics.

 Flow Predictability: This helps measure the predictability of the team and ART

based on business value points

 Flow Distribution: Percentage of backlog item type (business features, enabler

features, technical debts), etc in each PI

 Flow Load: This indicates the total number of Work In Progress items at any point

of time during the Program Increment execution. A cumulative Flow Diagram is

used to measure this.

 Flow Time: Measures the total elapsed time for all steps in the workflow to deliver

a backlog item or feature. This helps in increasing the speed of delivery in the

shortest time.

42
Interview questions for APM/SCRUM

 Flow Efficiency: This measures the value-added time spent in delivering value as

against the total time. This helps identify all the wastes in the system and remove

them.

Assessment based measurements

There are also assessments that can help measure the competency of the organization – for

example, team and technical agility, agile product delivery, continuous learning culture, etc.

What metrics are used in SAFe?

Metrics are pre-decided parameters which are used to measure how well an organisation is
performing and progressing to achieve its objectives. In SAFe, four metrics are considered:

1. Portfolio
2. Large solution
3. Program
4. Team
101. What are the features of SAFe version 6.0?

There are many changes in the SAFe 6.0 version, here are a few to highlight

 Big Picture changes – New measure and growth assessments, program and team

levels combined into essential SAFe, more clarity on the continuous delivery pipeline,

focus on Agile teams beyond technology, etc

 2 new competencies were added – continuous learning culture and organizational

agility

 5 restructured competencies – All the other 5 competencies were restructured to

provide more dimensions and a detailed explanation

 Focus on Business Agility is one of the highlights of SAFe 6.0

 New Overview tab with 7 core competencies listed

 A New Assessment called “Business Agility” assessment added

 Lot more focus on “Customer Centricity” and “Design Thinking”

 “Organize around Value” is the 10th principle added to SAFe 6.0

 LPM and APM certifications are added to the SAFe Implementation Roadmap

43
Interview questions for APM/SCRUM

102. What is Innovation and Planning iteration?

Innovation and planning iteration is one of the iterations in the Program Increment. This

iteration is the last iteration in every PI. The uniqueness of this is as the same says – it

focuses on “Innovation”, “Planning preparation” and “PI planning”. It also helps the teams

upgrade themselves through continuous learning.

IP iteration is the iteration where the Inspect & Adapt event is conducted which includes PI

System Demo, PI Retrospective, and Problem-solving workshop.

The other key difference in IP iteration compared to other iterations is – there is no value

delivery planned during this iteration. It’s primarily for innovation focus, learning, planning

preparation, and PI planning.

103. What are some pros and cons of SAFe?

Please read the detailed blog written on “Pros and Cons of SAFe”.

104. What are “story”, “Feature” and “epic” in SAFe?

Epics, features, and stories are the backlog structure in SAFe.

Epics are the large backlog items that require more than a PI to deliver the value. Epics can

be Portfolio epics, Solution epics, and program epics. They are large enough that it takes

more than a PI or two. Epics can be business epics or enabler epics.

An epic is typically defined at the portfolio level. It is a container for a significant solution
development initiative. The two types of epics are:

 Business epics - They are customer-facing initiatives that directly deliver business
value.
 Enabler epics - They are used to develop the Architectural Runway (existing code,
components, and technical infrastructure) to support future business epics. These
epics typically cut across different values streams.

Features are the ART level backlog, that will be delivered by the ART within a PI. Like epics,

they can also be Business Features and Enabler features.

Both feature and capability are part of the artifact hierarchy defined by SAFe. A feature is a
service that fulfils the requirement of a stakeholder. The two concepts of a feature are benefit
hypothesis and acceptance criteria. A capability is similar to a feature but is a higher-level
solution behaviour that cuts across multiple ARTs.

44
Interview questions for APM/SCRUM

The story is a team-level backlog that the Agile team can deliver within an iteration. They are

small enough that a single Agile team can deliver multiple stories within a PI.

105. What do you understand about a Value Stream?

Value Streams are the steps that any organization uses to implement and deliver solutions

and provide a continuous flow of value to their customer. The organization is typically sliced

based on functional or organizational silos that don’t allow the organization to deliver

customer value in the shortest time. The silo-ed structure causes many challenges like

1. Value delivery is slowed down due to handoffs and delays

2. The organizational boundaries don’t enable customer-centricity adoption

3. An organization is designed to optimize the work in silos, not as a whole

Value Stream thinking helps remove these challenges by bringing all the functions together

and delivering value to customers as one team.

There are 2 types of Value Streams.

1. Operational Value Stream

2. Development Value Stream

Here are the benefits of implementing value-stream thinking in the organization

1. Delays and Handoffs are fewer

2. Enables the teams to work as a single, long-lived unit that focuses on delivering

continuous value to customers

3. It enables the shortest sustainable lead time by identifying and removing waste in the

system

4. Increases the quality of the product

45
Interview questions for APM/SCRUM

106. 11. What is the purpose of having a System Demo?

System Demo is the demonstration of the whole system built by all the teams of an ART

incrementally in every iteration. This helps the leaders, and all stakeholders understand the

system that is built by the entire ART.

It provides an integrated view of all the features that are built in the recent iteration by all the

teams of an ART. It takes place at the end of every iteration. This helps stakeholders provide

feedback on the system the moment it is built.

Participants of the System Demo are Product Managers, Product Owners, System Team

members, System Architects, Business Owners, other executives and stakeholders who are

interested in seeing the demo, and ART agile team members as needed.

107. What do you understand by Release on Demand?

Release on Demand is a process that enables the deployment of new functionality into

production and releases instantly or incrementally based on the demand of the customer.

Release on Demand is part of the Continuous Delivery pipeline. “Based on demand” raises

the following questions to be answered

1. When should we release the new functionality?

2. Which elements of the system that is built should be released?

3. Who should receive the release content (ex., end users, market, etc)

A few practices that contribute to effective release on demand are

1. Dark launches

2. Feature toggle

3. Canary releases

4. Decouple release element

108. Is there any difference between User Stories and Enabler Stories?

Primarily, user stories refer to the stories in which the delivery directly corresponds to the

user who would utilize them. User stories deliver value to customers.

46
Interview questions for APM/SCRUM

Enabler stories don’t deliver any value directly however they enable value delivery. There are

4 types of enablers

1. Infrastructure enablers

2. Exploration enablers

3. Architectural enabler

4. Compliance enablers

To know more about enablers, read “What are enablers in SAFe?”

109. Explain the role of a Release Train Engineer.

Release Train Engineer, also known as RTE, is a chief scrum master of the Agile Release

Train. He/she is the servant leader and coach for the Agile Release Train. The critical

responsibility of RTE is to facilitate all ART events and help teams in delivering value to

customers faster.

A few key responsibilities of RTE are

1. Manage and optimize the flow of value

2. Facilitate all ART events (PI planning, System Demo, Scrum of Scrum, PO Sync, Inspect

& Adapt)

3. Coach leaders and teams on Lean-Agile practices and mindset

4. Escalate and track impediments

5. Help manage risks and dependencies

To know more about RTE, read the article “What is RTE in SAFe?”

110. How is SAFe different from Scrum?

Scrum is the agile framework followed by the team to deliver value in an incremental and

iterative way. It helps one single team to work on a backlog and deliver value with high

quality. Scrum focuses on 1 single team. It’s not designed to make more than 1 team deliver

common value to customers.

SAFe is a Lean-Agile framework followed by multiple agile teams that work together to deliver

1 common product or solution. When there are 5 or more teams working together to deliver a

47
Interview questions for APM/SCRUM

solution, SAFe is the right framework. SAFe borrowed the best of its values from Lean, Agile,

Systems Thinking, and DevOps.

111. How do agile teams define PI objectives and how is it useful?

Read the blog “Drive your Agile teams in SAFe through PI objectives”

112. What is Inspect and Adapt in SAFe?

It is known as one of the significant events that will happen at the end of each Program

Increment (PI). The PI mentioned here generally consists of 8-12 weeks. During this period,

the Agile Release Train delivers incremental value to the customer which is the fully working

systems built in the last 1 PI.

The current state of the product along with the process which was used to get to that position

is being discussed during the I&A event which happens at the end of every Program

Increment (PI).

With this event, it can be made sure that the upcoming PI is going to be better and more

efficient. Inspecting and putting efforts into improving the product as well as the process will

help in getting there. The event is attended by the stakeholders as well and they help in

providing the inputs that are added to the backlog of the next PI planning.

In the SAFe Agilist training, you will be able to learn more about PI and how to calculate the

metrics as well.

How does this Work?

Inspect & Adapt consists of 3 parts

1. The PI system Demo

2. Quantitative & Qualitative Measurement

3. Retrospective and problem solving workshop

The PI System Demo

48
Interview questions for APM/SCRUM

The first part of I&A is the PI System Demo. As the name suggests, the ART would showcase

the current system that was built in the last 1 PI. This will cover a larger set of people in the

event so that this information is available to all. This includes all the key stakeholders from

Portfolio, Customers to attend the demo.

This is to demonstrate the solution that was built the entire ART during this PI. This event is

time-boxed to 1 hour. The focus of this event is all about product demo.

At the end of the PI system demo, Business Owners connect with each team and rate their

team’s PI objectives by providing actual business value.

ref: Scaled Agile

Quantitative & Qualitative Measurements

This is another 60-minute session where quantitative, as well as qualitative measures, are

being taken to evaluate the products and processes that are part of ART. In this event,

Program / ART level metrics are displayed to the entire audience. One of the primary

measures displayed is “Program Predictability Measure”. Each team’s predictability based on

49
Interview questions for APM/SCRUM

business value delivery is measured and then the overall program predictability is

consolidated, like it is depicted in the below picture.

ART can also measure few qualitative measures like agile assessments, product delivery

assessments, role specific assessments etc.

Retrospective

The teams come together and addresses the issues that need to be put on the table during

the problem-solving workshop. From the issues that they have identified in different teams,

they will choose the top few issues for the problem-solving workshop.

Teams can use any of the retrospective techniques to conduct this retrospective to identify

their issues.

Problem-Solving Workshop

50
Interview questions for APM/SCRUM

ART comes together and conducts this workshop to identify 1-2 key problems, find root

causes and find solutions for the root causes. This is a six-step process.

The whole process takes approximately 4 hours for the entire ART. Let’s quickly look at

each step.

1. Agree on the problem to solve

A well stated problem is half-problem solved. Hence, it is critical to identify and state the

problem clearly. A well-stated problem addresses “What?”, “Where?”, “When?” and “Impact”.

2. Apply root-cause analysis

Once the problem is well-stated, team gets into identifying the root causes for the problem, in

– process, people, tools, program and environment.

3. Identify the biggest root cause

There can be multiple root causes for a specific problem identified. Its not humanly possible

to fix all the root causes, hence its important to identify the biggest root cause. This is done

using Pareto analysis tool.

51
Interview questions for APM/SCRUM

4. Restate the new problem

This step is to restate the problem with the biggest root cause identified.

5. Brainstorm solutions

Identifying some potential solutions is the objective in this step. Here are few rules for

applying brainstorming

 Come up with as many ideas as possible

 All ideas are welcome

 Combine / merge ideas

6. Create Improvement backlog items

The last step is to identify 1-2 solutions that can be implemented in the next PI itself.

RTE facilitates the entire I&A event.

113. What is the role of Product Management in SAFe?

Product Management in SAFe owns the definition and support building desirable, viable,

feasible, and sustainable product that meets customer needs. The product Management team

in SAFe drives a customer-centric mindset using Design Thinking tools.

The top responsibilities of Product Management are

– Meet business goals

– Get it built

– Get it off the shelf

– Leverage support

It is one of the key roles of Agile Release Train to define the vision, roadmap, and backlog for

the entire ART.

114. How do Agile and SAFe Frameworks differ? What are the four core values of
SAFe?
Agile is a broad term that covers several frameworks, out of which one is SAFe. This SAFe
framework, established by Dean Leffingwell, is specifically for large-scale enterprise projects

52
Interview questions for APM/SCRUM

as it scales up other models like Scrum to an enterprise level. It is based on three

fundamental principles: Agile Development, Lean Product Development and Systems
Thinking.
The four core values of SAFe are:
1. Alignment - Keeping pace with the rapid changes
2. Built-in quality - Every element must be up to the quality standards
3. Transparency - Trust and reliability
4. Program Execution - Deliver continuously and efficiently
115. What are the various dimensions of built-in quality?
Built-in quality has five dimensions:
1. Flow
2. Architecture and Design Quality
3. Code Quality
4. System Quality
5. Release Quality
116. What are the different levels of SAFe?
The four levels in version 6.0 of SAFe are:
1. Team: Involves a small Agile team of 5-10 people to deliver a working system in two
weeks
2. Program: Multiple teams (100-125 people) work together, including other
stakeholders; this is called the Agile Release Train (ART)
3. Value Stream: At this stage, there is a collaboration between the solutions architect
and the value stream engineer, who acts as a guide
4. Portfolio: This is a collection of value streams. Portfolio managers are responsible for
delivering business results.

117. What are the core competencies in the latest version of SAFe (v 5.0)?
SAFe 5.0 was launched in January 2020 and has seven core competencies revolving
around customer-centricity. They are:
1. Enterprise solution delivery
2. Agile product delivery
3. Team and technical agility
4. Lean-Agile leadership
5. Lean portfolio management
6. Continuous learning curve
7. Organisational agility

118. What is iteration review in SAFe?

It is a regularly occurring event where every team analyses the increment at the end of every
iteration (the standard fixed-length time window) and accordingly modifies the team's
backlog based on the feedback of the stakeholders and the product owner. It gives the Agile
teams a chance to showcase their work and for the stakeholders to monitor the progress.

119. What's the difference between user stories and enabler stories?

User stories are stories which deliver functionality directly to the end-user. These are usually
written in simple language that the user can understand, and this language will also help the
Agile team appreciate what the user wants.

Enabler stories give an insight into the work items needed to support exploration,
architecture, infrastructure and compliance. These may never be seen by the end-user, and
are often written in technical language.

53
Interview questions for APM/SCRUM

120. What is a feature and what is a capability?

Both feature and capability are part of the artifact hierarchy defined by SAFe. A feature is a
service that fulfils the requirement of a stakeholder. The two concepts of a feature are benefit
hypothesis and acceptance criteria. A capability is similar to a feature but is a higher-level
solution behaviour that cuts across multiple ARTs.

121. What are some disadvantages of SAFe or Agile?

In general, any method or framework will have pros and cons, and it is good to be aware of
both to have a balanced viewpoint. Although Agile methodology is followed across industries,
it does have limitations like:
1. Since Agile deals with continuous development and innovation, long-term goals are
rarely set; there is considerable incoherence in long-term planning.
2. In SAFe, managers are often assigned multiple projects at once, and this could make
the process less efficient because of delayed responses. The actual product
developers don't have as much freedom in the SAFe model as they do in other
models like Scrum.
3. SAFe adopts too much of a top-down approach. The project goes in sequential order,
i.e. the project development team proceeds to next stage of development only if the
previous step is completed successfully - while most industries are attempting to
move away from this model to more efficient ones.
122. What are the nine principles of SAFe?
The principles of SAFe are based on Lean and Agile methods, as well as lessons learnt from
plenty of actual deployments.
1. Take an economic view
2. Apply systems thinking
3. Assume variability and preserve options
4. Build incrementally with integrated learning cycles
5. Base milestones on objective evaluation of systems
6. Visualise and limit work-in-progress, reduce batch sizes, and manage queue lengths
7. Apply cadence (timing), synchronise with cross-domain planning
8. Unlock the intrinsic motivation of knowledge workers
9. Decentralise decision-making

Recently, a 10th principle is also stated: "Organise around value".

123. How does decentralised decision-making fit into the SAFe model?

The primary motivation behind this concept is to shorten the lead time, or in other words, the
feedback process is faster because there's no delay in waiting for specific higher authority to
respond. Note that the decisions which have a far-reaching impact or those which are beyond
the scope of certain teams will need the intervention of a higher authority, but, by and large,
the time-critical decisions are decentralised.

124. What are the shared services? Does SAFe benefit from this in any way?

Shared Services consists of the people, services and speciality roles needed for an ART to
succeed, but which cannot be devoted full-time. Shared services can improve efficiency by
quickly assigning experts of an area of the system that requires unique knowledge, without
looking for a full-time availability.

125. What is meant by tipping point?

An enterprise reaches its tipping point when the dominant organisational motive is to achieve
change rather than resist it. The status quo becomes so unacceptable that making a change
is the only way forward.

54
Interview questions for APM/SCRUM

126. Scrum Vs SAFe?

Category Scrum SAFe

Organization structure Small organizations with Enterprises with interconnected
independent teams teams
Development philosophy Fast, continuous development Goal setting with organizational
commitment
Implementation Small teams with straightforward Organizations tackling complex
goals projects across teams
Processes Lightweight, flexible, and iterative Clear objectives set with a
software delivery predetermined schedule
Framework requirements A whole team must embrace An entire organization must embrace
Scrum SAFe
Team roles Less than 12 members broken into Dozens of employees working within
three roles several roles
Dependencies Coordination within teams Alignment between teams
Timeframe Sprints last one to four weeks Sprints last two weeks

127. How do you measure Lead Time and Cycle time?

Lead time is the metric used to measure the time from the moment a customer placed the

order to the time that the order is delivered to the customer.

For example, let’s assume that the customer placed the order on 10 th September and the

order is delivered to the customer on 20th September, the total lead time is 10 days. It’s the

total time taken between the customer’s need and the value delivery to the customer.

In short, it is the latency between initiation and completion of the process. In the Car

manufacturing example, Lead time includes order preparation time, setup time,

manufacturing time, assembly time, inspection time, and transportation time till it reaches

the customer.

What is the Cycle Time?

Cycle time is the subset of the total Lead Time. Cycle time is the amount of time taken to

actually start working on the production of the item up until the product is ready to go for

shipment. It starts when the work starts, and it is moved to the “In Progress” state and it is

done when it is ready for release to the customer. The below picture depicts both well.

55
Interview questions for APM/SCRUM

The cycle time will include the time needed to produce the item including the wait time as

well.

Lead Time VS Cycle Time: Examples

Let’s take a few examples to understand where to focus.

1. Lead Time and Cycle time are almost the same

Lead Time is 50 days and cycle time is 45 days. This means, most of the lead time is in

execution because cycle time is almost the same as Lead time. In such a case, focus on each

process step of a cycle time and identify improvement areas. Improving cycle time will help

improve the lead time.

2. Lead Time is way bigger than the cycle time

Look at the below picture. Lead Time is 50 days and cycle time is 10 days. This indicates that

the Lead Time is much longer compared to the cycle time.

56
Interview questions for APM/SCRUM

The improvement focus on reducing the Lead Time should be beyond the cycle time window.

For example, look at the process elements that are before the cycle time start (before the “In

Progress” state) and after the cycle time (post ready for the production release).

3. Look at another example. In this example, the lead time is 500 days and the cycle

time is 250 days. Where do you focus on improvement here?

Since both are too long periods, it is important that we focus on process steps to identify and

eliminate waste from both cycle time and beyond cycle time. Identifying the bottlenecks and

removing the biggest bottleneck will be the ultimate goal of having these measurements.

How do we use Lead Time & Cycle time?

Let’s now look at what we get by measuring both Lead Time and Cycle time. Finding these

will help us to understand the total time taken and will lead to the identification of

bottlenecks and removal of the same. What if there are multiple bottlenecks in the entire

flow? Focus on removing the biggest bottleneck.

Examples of Lead Time & Cycle time in Layman terms:

Let me try to explain these again in layman’s terms with some real-time examples.

1. Cycle time is the time to make the sandwich from the start of the preparation. Lead

Time is the time taken to deliver the sandwich from the time the order is taken.

57
Interview questions for APM/SCRUM

2. Cycle time is the time taken to manufacture a car and keep it ready to ship from the

start time. Lead Time is the total time taken to hand over the finished car from the

time the order is placed by the customer.

How do we use Lead Time & Cycle Time in Software?

In Software, Lead Time starts when the requirements are expressed by the customer and

entered into the product management/backlog management system. Lead Time is considered

till that specific backlog is released to the customer.

Cycle time measurement starts when the work is moved to “In Progress” by the

engineering/development team. It is considered till it is moved to the “Done” state. Done

doesn’t mean that it is released to customers, but it is done from engineering and ready for

release.

What are the Differences Between Lead Time and Cycle Time?

Now that we are aware of what is cycle time and lead time, it is time for us to know their

differences.

Difference 1: As I mentioned earlier, the cycle time officially starts when the item is moved

to “In Progress” and it ends when the item’s status is changed to “Done”.

Lead time will be calculated as the time it takes for the single unit of product to be created

(say a backlog item) and then added to the product/program backlog and till it is shipped to

the customer.

Difference 2:

Cycle time is always measured from the perspective of the manufacturer, whereas Lead Time

is from the perspective of the customer.

Difference 3:

58
Interview questions for APM/SCRUM

Cycle Time helps measure the time and identify the bottlenecks only in engineering. Lead

Time helps measure the total time and identify the bottlenecks across the system from

request to release.

As they are very important in product development, you should understand them in depth

with the best Kanban management professional certification courses that are available on

various platforms. We will discuss this part in the end. So let us begin to get some useful

information about these useful metrics.

One of the metrics to measure both Cycle time and Lead time is the “Cumulative Flow

Diagram”.

Benefits of Calculating Cycle Time and Lead Time

1. Cycle time helps determine the overall efficiency of the production unit/engineering

teams etc. Lead Time helps determine the total time taken to deliver value to

customers from the order time. Both help measure the actual time taken.

2. Both help identifies the bottlenecks in the system flow that led to the longer cycle

time and lead time. Most of the time, the bottlenecks are not in the execution, but

they are the biggest wastes in the system. These metrics help identify wastes in the

system.

59
Interview questions for APM/SCRUM

3. Lead time plays a great role in estimating the demand. Alongside this, cycle time is

also a key metric that helps in understanding the efficiency of the process and how

much time it takes for the backlog to be delivered.

Both these factors can provide great insights to the team and make sure that they are putting

efforts in the right direction and giving their best to reduce both these time metrics.

Tips for Reducing Cycle and Lead Time in the Project

Below are some of the tips that you can use in your project to reduce these time metrics and

have perfect efficiency in the developmental processes.

Invest in good project management software

If you think that calculating the project cycle and lead time can be a daunting task, then you

should try accessing the project management software that can help you measure Lead Time

and Cycle Time. Calculating these metrics manually is a huge task that cannot be

sustained.

Automate your process

The best way to reduce Lead Time / Cycle Time is to automate the processes that are

creating bottlenecks. Here is an example of automation.

Process Automation: There are many IT-intensive business processes that are needed to own,

administer and manage various process elements. Automating these business processes will

eliminate unnecessary waiting waste and defect waste.

128. What is Kanban?

To read more about the Kanban board, please read the article “Kanban Board”

RCM Products
AFD

60
Interview questions for APM/SCRUM

61