Intermediate and Advance Question Agile:
What is the Agile manifesto?
The Agile Manifesto lays out values that help teams get into an Agile mindset. When everyone on the
team genuinely incorporates these values into the way they think, it helps them build better software.
Following are the Agile Manifesto –
Individuals and interactions over processes and tools: While Agile team value processes and
tools as it helps the team get organized and work effectively, they value people and interactions more
because teams work best when they are self-organized, motivated, co-located and pay attention to
the human element.
Working software over comprehensive documentation: While Agile team values comprehensive
documentation because it’s an effective way to communicate complex requirements and ideas, they
value working software more because it’s the most effective way to communicate progress,
understand evolving requirements and get feedback from users.
Customer collaboration over contract negotiation: While Agile team values contract negotiation
because sometimes it’s the only way to work effectively in an office culture where mistakes are
punished, they value customer collaboration more because it is much more effective to get proper
production requirement for building software.
Responding to change over following a plan: While Agile team value following a plan because,
without planning, complex software projects go off the rail, they value responding to change more
because the team that works on the wrong plan ends up building the wrong software.
2.When the Agile manifesto says ‘People over Process’, why do we still need a Scrum Master,
a role meant to enforce the Scrum process?
While there is value in the manifesto items on the right, the Agile team values the items on the left
more. A Scrum team is like a family where each person has different roles. A Scrum Master's role is
one where the person focuses on removing the impediments and is also the process champion.
Hence, a Scrum Master helps the team get more organized and work effectively by adopting some
best practices and processes. Having said that, Scrum Master’s primary responsibility is to help the
team be more successful.

3.Why should we value responding to change more over following a plan?
While it’s natural to resist a big change, if a team can find a way to not just accept but welcome these
changes, it means that they’re putting the users’ long-term needs ahead of their own short-term
annoyance. In a context which is dynamic, one cannot specify and plan in detail because the context
changes before one can deliver. In such a case, continuing to deliver as per plan will lead to low staff
motivation due to a failed project and lost opportunity due to an unsatisfied customer. Responding to
change is not only more effective, but it is also imperative for companies that must compete in a fastpaced, cutthroat, rapidly changing marketplace. Scrum responds to changes between sprints but still
follows a plan during sprints. That’s why we value responding to change *over* following a plan, not
*instead* of.

4.What are the principles of Agile testing?
Agile testing principles complement general Agile principles and are as below:
1. Testing is continuous and sustainable to ensure there is continuous progress of the product.
2. Continuous feedback is essential and is provided on how a given product is meeting the
business needs and customer satisfaction.
3. Testing is performed by a self-organized team, unlike in a traditional software development
life cycle where only the test team is responsible for testing.
4. Face to face communication with the business team involved in each iteration in Agile testing
for continuous feedback and successive improvement.
5. Simplified & clean code by ensuring all the defects which are raised by the Agile team are
fixed within the same iteration.
6. Test Driven in Agile methods, testing is performed at the time of implementation unlike after
implementation as in the case of the traditional process.
5.Explain Velocity in Agile.
Simply expressed, velocity is the amount of work that a team can get done in a fixed timeframe. It
indicates the average amount of Product Increment created during a Sprint by a Scrum Team. A
Sprint Burn-down Chart is a helpful tool is used by the Scrum Team to maintain and share information
about the team’s velocity. While a Team's velocity will vary each sprint, over time, a well-functioning
Scrum Team's velocity should steadily trend upward each Sprint. With the knowledge of team
velocity, a Product Owner can project on how many sprints are required for the team to deliver the
desired level of functionality that can be released. Since different teams may have different
approaches to estimation, we should avoid comparing velocity between teams.

6.What is the difference between sprint burn-up chart and burn-down chart?
Burn down and burn up charts are two types of charts that scrum team use to track and communicate
the progress of their projects. A burndown chart shows how much work is remaining to be done in the
project, whereas a burn up shows how much work has been completed, and the total amount of
work.
As the progress is measured independently on scope change, the burn-up chart makes progress
perfectly visible.
So, the mechanics are basically the same. The only difference is that instead of tracking how much
work is left to be done, it tracks how much work is completed, so the curve is going up, not down.
7.What is Sprint Zero in Agile?
Contrary to popular believes that Sprint Zero is necessary because there is some groundwork that
needs to be done before a Scrum project can start (for example, a team needs to be assembled, a
hardware to acquire or at least set up, an initial product backlog is to be written), it is used to create a
minimal design so that a detailed design can emerge incrementally in an efficient way in future
sprints.

8.What are the guidelines for a potentially shippable product?
Potentially shippable act as a reminder that the developed features may not be sufficient enough to
be truly shippable. While each organization or team establishes an appropriate Definition of Done for
its context, there are certain guidelines that are applicable across most Scrum projects.

It should be well written and tested to a point that no important bugs remain.

It does not necessarily have to be cohesive, i.e. it doesn’t mean anyone wants us to actually
ship it yet but if someone had wanted it, the team could have shipped it.

It should be well integrated to the extent that integration should be done continuously
throughout the sprint.
9.What are the salient traits of a cross-functional team?
The ability for a team to be cross-functional is fundamental to all agile methodologies. A crossfunctional team should be balanced on technical skill levels and domain knowledge should be diverse
and persistent. The team structure should reflect that of a feature team who can better evaluate the
impact of design decisions. A cross-functional team need to be balanced between being too
generalists and being to specialists and it does not require any specific role.

10.What do you understand by the three elements of a user story: Card, Conversation, and
Confirmation?
As per Agile Manifesto Principle 6, “The most efficient and effective method of conveying information
to and within a development team is via face-to-face conversation”. To encourage this rich form of
communication, a user story card is intentionally kept as brief as possible and has 3 elements:
Card: The user story card includes just enough text to identify the story because the card is simply a
token that represents the requirement for the planning process.
Conversation: The details of the story are communicated via a conversation – a verbal exchange of
ideas, opinions, and information between the customer and the development team.
Confirmation: This means that the product increment passes the customer’s acceptance test and
meets the agreed upon definition of “done”.
11.What are the characteristics of effective user stories?
To build a good user story, Bill Wake described six characteristics of a good user story –
Independent: Ideally, our goal is to be able to reprioritize and develop our user stories in any order.
And this can be achieved, though hard, by creating independent user stories that can be selected on
merit, rather than dragging into the release because other user stories depend on it.
Negotiable: The team should be able to discuss user stories with the product owner and make tradeoffs based on cost and function. Negotiating user stories leads to an improved understanding of the
true requirements, costs, and acceptable compromises.
Valuable: User stories without clearly understood business benefits will be difficult to prioritize, since
backlogs are usually ranked in business value. And if we cannot determine the value of a
requirement, then we should question why it is a part of the project.
Estimable: Estimation is required to prioritize work based on its cost-benefit trade-off.
Small: Small user stories are easier to estimate and test than large user stories.
Testable: Having testable user stories is important for tracking progress because agile teams often
measure their progress based upon the number of stories that have been successfully accepted.
12.What are the best practices for estimating user stories?
The best approach for estimating user stories is one that
Allows us to change our mind whenever we have new information about a story

Works for both epics and smaller user stories

Doesn’t take a lot of time

Provides useful information about our progress and the work remaining

Is tolerant of imprecision in the estimates

Can be used to plan releases
13.If a team member encounters a tricky problem during a development iteration, what does
agile recommend?
Agile teams rely on collective problem solving rather than individual ingenuity because problems are
solved more quickly and effectively when diverse viewpoints are brought to bear, rather than when
team members try to push through their own. And although it is the Scrum Master’s role to remove
impediments to progress, that refers to eternal roadblocks. When it comes to development issues, in
many cases only the team members have the expertise needed to resolve the issues.
14.What are various agile models?
Agile models are lightweight, barely sufficient models that aim to capture the high-value benefits of
modeling without taking too much time to create very detailed or polished models. We want to focus
on the product being developed, rather than on generating documentation.
The most popular agile models include: Scrum, Lean and Kanban, XP, DSDM, and FDD.
15.What are the various steps involved in iteration planning process?
Iteration planning begins with a meeting that includes the delivery team, the product owner, and
possibly other stakeholders or SMEs as needed.
In the first half of the meeting, the product owner describes the backlog items they’d like to see
developed in the sprint, and based on that, the team members select a set of items that they think are
achievable.
In the second half of the meeting, the team breaks down the selected backlog items into the smallest
unit of work to come up with a list of action items for the iteration.
In summary, we need to accomplish the below steps during the iteration planning process –

Discuss the user stories in the backlog

Select the user stories for the iteration

Define the acceptance criteria and write acceptance test for the stories

Break down the user stories into tasks

Estimate the tasks
Can Scrum be applied to all types of Projects?
This is a very good interview question. And the expectation of the interviewer is that you should
have a clear understanding of Waterfall and Agile.
So, the answer is “NO”. Both approaches have their own strengths and weakness, so it
all depends on the type of project and its environment. Both have effective planning, execution
and controlling.
Below table clearly defines the scenarios, when to use Scrum to achieve better results.
When to use SCRUM
When to use Waterfall (Traditional Method)
Scope not clearly defined.
The scope is clearly defined upfront
Requirements changes frequently
Requirements are well defined
The Project is complex and unpredictable
The Project is simple and predictable
Incremental results have value and can be used by
users (Production)
The Product cannot be used unless it reached its
milestone
Customer available
Customer may or may not be there.
Scrum is not a prescriptive method, but a suggestive approach to software development. So, the
way it is implemented makes all the difference.
Then the interviewer may give you one case study and ask you to find which will be the best
Methodology.
Situation: When there are a lot of issues (Maintenance project or Ticketing project) from the
field and the current project team is handling both the things (current project and field issues)
which methodology best suits?
The Interviewer is expecting the knowledge of Kanban and Scrum both.
So, in my opinion, the answer will be the Scrumban (Scrum+Kanban) approach. Because here
requirements are changing so frequently which is hampering the current project and sprint.
Scrumban is specially designed for a project that requires frequent maintenance, having
unexpected user stories and programming errors. Using this approach, the team’s workflow is
guided in a way that allows minimum completion time for each user story or programming error.
As in this approach, we will not take up a new task until the high priority task has reached the
deployed state.
The below board depicts the above situation.
2.Have you faced any situation where your delivery team is not getting along? Which stage
are they in? How to handle this situation?
The intention behind this question is to indirectly ask the responsibilities of the Scrum Master or
a leader. He is expecting the real-time experience which you have faced.
Every team will go through 4 stages of group development which is Forming, Storming, Norming,
and Performing.
FormingMost team members are new, polite and humble at this stage also the roles and responsibilities
are not clear to the team.
StormingStorming can also happen in other situations. Example: Team members may challenge your
authority, or jockey for position as their roles are clarified. Or, if you haven't defined clearly how
the team will work, people may feel overwhelmed by their workload, or they could be
uncomfortable with the approach you're using. This is the situation where many teams fail.
NormingThis is when people start to resolve their differences, appreciate colleagues' strengths, and
respect your authority as a leader.
PerformingThe team reaches the performing stage, when hard work leads, without friction, to the
achievement of the team's goal. The structures and processes that you have set up support this
well.
As a leader, you can delegate much of your work, and you can concentrate on developing team
members.
The same is depicted in the figure below.
As a leader, we should handle this situation very diligently. My approach could be:
1. Analyze the reason for conflict.
2. Talk to the team members individually and try to understand them from their
perspective.
3. You should make them understand the common goals of the team and work towards it,
as Scrum always believe in collaboration over tools and processes.
4. Guide them to take criticism as a step towards your success goals.
5. Do more frequent team outings and team building events.
6. After each sprint completion appreciates the efforts put in by each team member and
celebrate this by organizing small snacks or lunch get together after retrospection.
3.What type of Requirements did you use for your project? If the customer wants to change
the requirement in the middle of the sprint, how to handle this as a Tester and Developer?
In SCRUM approach User Story is used as a requirement. The best way to write the user story
is “As a ___, I want___ so that I can ___.”
Example: As a user, I want to login to the screen so that I can book the tickets.
The test for determining whether or not a story is well understood and ready for the team to
begin working on it is the INVEST acronym:
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
This is a very common scenario seen in the projects which are using Scrum Approach. The team
should always be prepared for that. But try to have a good conversation with the Product owner
to not include in the current sprint and deferred to the next sprint. Changes in requirements
sometimes taken as a feedback from the customer so that the product can be improved. We
should be ready to embrace this change.
As a tester, they should take the generic approach by writing the generic test cases (Login
screen, user credentials). Till the requirements are stable, try to wait if you are planning to
automate the test cases.
As a developer same approach can be used where chances of changes are minimal. Try to code
using design patterns and oops concepts (Components or package independent of each other),
so that change in one component make minimal changes in another.
4.You are starting a new project with a new team and have to use Scrum for this project, what
and all the things that need to be done before the project kick off?
A very good interview question for an experienced person.
1. First, check that the project is suitable for applying Scrum or not. Check Question 1 for
more details.
2. If the project looks suitable for Scrum, then get the details of the Project like (Skillset
required, requirements, technical details etc.).
3. Get the details of the team members to example their skill set, prior knowledge of Scrum
etc.
4. If the entire team is new to this process, then it is very important to send them for the
basic Scrum training. (If you are capable of doing so, tell the management about it.)
5. Have a good balance of Developers, Testers, Architect, DevOps Engineers with good
technical skills required for the project. (Doesn’t mean the best technical knowledge in
one team).
6. Have one on one and various group meetings to clarify their doubts and explain their
responsibilities. Discuss the Agile Manifesto and 12 principles and encourage them to be
self-organized and work with collaboration.
7. Co-locate the development team removes any partitions, bookcases, furniture if any.
8. Get some whiteboards permanently for your team, select the place for daily stand up.
Make sure the board is right in front of a team where the daily meeting is held.
1. Select any Project Management tool which fulfills all your requirements (Jira, Rally etc.)
2. Co-locating the Development Team, will help empower them to self-organize, makes it
easier for the team to learn from each other (cross-functional), and fosters direct, faceto-face communications.
3. Explain to the team about the “Definition of Done” which is a very critical part, as we do
not want to compromise on the quality of the product.
4. Set up the DevOps environment and get the continuous build integration, automation
right from the start of the project.
5.What is a velocity? This is your first iteration of 2 weeks, how you will decide the velocity?
Does maximum velocity mean maximum productivity?
In simplest terms velocity is the sum of story points completed in one sprint. From my
perspective, velocity is like other metrics of the scrum which should be used for planning
purposes i.e. how many user stories can be incorporated for any release or sprint. Velocity
should remain constant if the team conditions remain the same. If there is any change with
respect to the team, the change in velocity is also expected.
But, how to calculate the team’s first velocity during planning.
The general rule is to plan one-third of the capacity of the total team members.
Example: If there are 6 programmers and 2 weeks iteration then there will be 60 programmer
days, one-third of this will be 20 story points which we need to plan. As this is a new sprint and
a new team, it will take some time to stabilize. And also some time may be for meetings, emails,
designs etc.
The second way is to take the history of the team progress in other projects. (Condition-If the
team is the same or at least have the same skill set and worked on a similar project before.)
Also, remember that velocity will quickly emerge during the first iteration. If underestimated,
velocity in the first iteration will rise as new features are included; and if overestimated, velocity
will decrease as features are removed. For the second iteration, the Scrum team should then use
the first iteration as a guideline.
The graph shown below shows different velocities in different sprints. If we take the average
velocity (Green line) then it comes out to be 13 story points.
“Velocity is more of a quantity of work completed metric. Useful and important, but not the sole
measure of success. I think you would want a set of metrics that together help us understand
our current capabilities to deliver as well as if those capabilities are changing from one point in
time to another. I don't believe there is one magic "agility number" to measure
[productivity].”- Paul Hodgetts, Agile Coach
Which is important because according to the Agile Manifesto, “Working software is the primary
measure of progress.”
6.The Sprint got over and there are few tasks still not completed, how to handle this?
A very practical question. I have seen this happening in most of the projects where I worked.
There are multiple reasons for not completing the user story example-Dependencies, waiting for
some inputs, defects found, some unplanned work, team member went on unplanned leaves,
not estimated properly etc.
As a Product Owner we can handle this in below-mentioned ways:
1. Split the user Story.
The User Stories which are not completed can be transferred to the next sprint.
The tasks which are completed for this user story can be closed. We can re-estimate the story
again in the next sprint and take this story as a high priority in the next sprint.
1. Product Owner may also say that unless all the tasks of a user story are completed we
cannot accept. In this entire, a user story is transferred to the next sprint and reestimated. (Not completed tasks.)
But the question arises Does the team earns the velocity credit?
If we are deferring the unfinished user story to the next sprint then do not take the velocity
credit for it. Let the user story meets its acceptance criteria and then take the complete credit in
the next sprint. We already know that we use average velocity, this averages out and avoid the
risk of overstating velocity.
But in case of splitting the user story then take the credit of points burned for the work
completed and let the remaining points for the unfinished work in the next sprint. This just
boosts up the team’s morale as they have been given the points for the work completed and
efforts they have put in.
I am a bit reluctant in taking this decision. Take your call based on discussion.
7.What is SAFe? In which business scenarios it should be used and what are the principles?
SAFe (Scaled Agile framework) helps businesses address the significant challenges of developing
and delivering enterprise-class software and systems in the shortest sustainable lead time.
When to use SAFe:
1. When we want to implement an agile approach consistently across larger, multi-team
program and portfolios.
2. Project having 5-10 Scrum teams distributed across various geographical locations.
3. When a team wants to work independently.
4. When an organization wants to improve its product development lead time.
5. When you want to implement Agile across an organization and you are not sure of
various roles and responsibilities and how they align and coordinate with each other.
6. When multiple teams are running Agile, but regularly facing delays, no collaboration, and
failures.
7. Decentralized decision making.
The benefits of SAFe are:
Its principles are shown in the diagram below:
8.Do you know any other methodology other than Scrum, explain them?
Another agile methodology is Kanban, XP (Extreme Engineering, Lean thinking).
Let us compare the Kanban and Scrum Approach.
Scrum
Kanban
More perspective
Less
Limit your (WIP) PER ITERATION
Limit your (WIP) PER ITERATION
Prescribed Roles like Product owner, Scrum Master
No such prescribed roles.
Scrum resists change within an iteration
Free to add any task in “To do”
Scrum board is reset after each iteration
Not necessarily done as the focus is on to
finish one task completely and then remove.
Scrum prescribes cross-functional teams
The team can set the ground rules as who can
change/own the board, experiment and
optimize
Scrum backlog items must fit into a sprint
No such rule but Kanban focus on minimizing
lead time and level the flow.
Scrum
Kanban
Scrum prescribes estimation and velocity
No such things are prescribed but suggested a
way to break them into similar tasks and
estimate them roughly just to give an idea
about how much work can be completed per
unit of time
Allow working on multiple projects simultaneously
Can be distinguished by swim lanes or
different color coding
Burn down charts are prescribed to know the progress of
the sprint
No prescribed charts
Similarities

Both are Lean and Agile

Both use pull scheduling

Both limit WIP

Both use transparency to drive process improvement

Both focus on delivering releasable software early and often

Both are based on self-organizing teams

Both require breaking the work into pieces

In both, the release plan is continuously optimized based on empirical data
(velocity/lead time)
Scrum Board:
Kanban Board:
Now the whole workflow is on the same board. In the example above the “Backlog” column is
just a general Wishlist, in no particular order. The “Selected” column contains the high priority
items, with a Kanban limit of 2.
The “Dev” limit of 3 is shared among the two sub-columns. Why? Let’s say there are 2 items in
“Done”:
That means there can only be 1 item in “Ongoing”. That means there will be excess capacity,
developers who could start a new item but aren’t allowed to because of the Kanban limit. That
gives them a strong incentive to focus their efforts and helping to get stuff into production, to
clear the “Done” column and to maximize the flow. This effect is nice and gradual – the more
stuff in “Done”, the less stuff is allowed in “Ongoing” – which helps the team focus on the right
things.
Scrum is less prescriptive than XP since it doesn’t prescribe any specific engineering practices.
XP (Extreme Programming) is pretty prescriptive compared to Scrum. It includes most of Scrum
+ a bunch of fairly specific engineering practices such as test-driven development and pair
programming.
The five values of XP are communication, simplicity, feedback, courage, and respect.
1. Extreme Programming empowers your developers to confidently respond to changing
customer requirements, even late in the life cycle.
2. Extreme Programmers constantly communicate with their customers and fellow
programmers. They keep their design simple and clean.
3. They get feedback by testing their software starting on day one. They deliver the system
to the customers as early as possible and implement changes as suggested.
4. Every small success deepens their respect for the unique contributions of each and every
team member.
5. With this foundation, Extreme Programmers are able to courageously respond to
changing requirements and technology.
Lean Thinking:
The principles of Lean thinking are:
Lean says to relentlessly eliminate anything that isn’t adding value and only work on what we
absolutely need to be doing at this moment in time. Eliminating waste means eliminating useless
meetings, tasks, and documentation.
Lean says to respect that the people doing the work are the ones that best know how to do it.
Give them what they need to be effective and then trust them to do it. Software development is
about learning, so structure the work to ensure we’re continuously learning. Finally, develop in a
way that builds quality into our product, because there’s no way to continuously deliver fast if we
have to keep going back to clean up our messes.
9.How do you promote an agile mindset across departmental boundaries and throughout an
organization and, in pursuit of that, what is your strategy when coaching stakeholders not
familiar with IT?
More importantly the Agile practitioner should be the “seller of Agile” wherever he goes. His
heart and soul should think only about its principles, manifesto and different ways of
implementing it.
1. Engage people in this discussion by various means. Not necessarily in meetings can be in
during Lunch time, coffee time etc.
2. Arrange for different types of workshops to train them.
3. Call them for the sprint planning, review, and retrospection.
4. Discuss the velocity, lead time change from idea to product launch and level of customer
satisfaction during this process.
5. Arrange for small pilot projects for their domain to give them more insights into this
process.
6. Product and engineering teams can demonstrate that scrum mitigates risk (i.e. the
prediction of when new features could be made available), thus contributing to other
departments’ successes in planning and execution.
10.How do you deal with team members cherry-picking tasks?
Again a very important interview question as interviewer wants to know if you faced this
situation earlier, if yes how you overcome it.
This is a very important concern in any team and it needs to be solved very diligently.
Because cherry picking can be done by senior people also.
1. As an Agile Practitioner/Scrum Master/Product owner make sure in sprint planning
meeting you have clear, refined and prioritized backlog ready for the team to work.
2. As Scrum given the freedom to any individual to pick up any task…but hold on only on
the prioritized stories which are selected by your product owner.
3. Not doing that will lead to a lot of unfinished tasks at the end and your product may not
be in a condition to give a demo to the stakeholders.
4. If the team fails in understanding the goal of the sprint, the scrum master should help
him on this. Additional training might also help.
5. Let the cherry-picking task be transparent to everyone in the daily scrum (As we use
scrum board) and when everyone will see that work in progress are many and not
moving towards completed state then you can directly ask the team what the reason
could be and what are the possible ways to overcome them. Best way to show your
Scrum Master skills.
6. Some people may do cherry picking if they find something interesting task to be picked
up or easy task, but SCRUM is all about team goals, not an individual. An individual may
automatically succeed if the team succeeds.
For an interview this will be a trap so don’t tell that I will have to tell him to do this and
that…No micromanagement. Don’t try to take the driver seat…
11.
What are the different levels in safe? Explain in brief?
There are 4 different levels of SAFe in 4.0 version onwards.
They are shown in the figure below:

Team Level-:
This level is the same as that of what we know about Scrum, it’s Artifacts, roles and
events/ceremonies.
All scrum teams are part of one or the other ART (Agile Release train).
ART is explained in the below diagram. Basically, this is a team of 50-100 people (crossfunctional) responsible for defining and deploying the new system, plan, commit and delivers the
solution to the customer in a particular time frame.

Program Level:
At this level product and program manager has the authority to define the Backlog.
At this level, different roles are DevOps, System Architect, RTE, Product Management, System
Team, Business owners, Customer, UX Architect.
The main events of this level are:

ART:
1. This level value of SAFe is delivered by ART. Iteration is for the Team and train is for the
program. It delivers a value stream to the organization.
2. SAFe artifact hierarchy is Epics->features->user stories. User Stories then drill down to
the team level.
3. Various team (from marketing, development, quality, operations, and deployment) forms
'Release Management Team'. They will approve routine releases of quality solutions to
customers

PI planning-
Duration is about 8-12 weeks. A very huge event where all the cross-functional team members
across the globe participate and work towards the common goal. A valuable increment of the
system is developed and delivered.
PI deliverables:

System Demos-At the end of each PI (Every 2 weeks) the full integrated work of all
teams is demoed. This is in addition to each team iteration demo. Stakeholders provide
the feedback and corrective action needs to be taken if required.

Inspect and Adapt- This is also held at the end of each PI to demonstrate the solution,
get the feedback, solve the problem and identify improvement areas

Architectural Runway- It is an existing code base, components, technical infrastructure
on top where new features are developed without much change in code.

Release Any Time- This separates the development cadence from the solution release
cycle. Trains may release whatever is needed at any time.

Value Stream Level-This level is optional but required in below cases.

The organization is big in size
1. Complex solutions
2. The solution requires multiple ART’s
3. System challenges

Portfolio Level-
Highest level of concern/involvement in SAFe is portfolio Level.
1. It provides basic budgeting and other governance mechanisms.
2. This way it assures that investment in the value streams provides the basic returns for
the enterprise.
3. Portfolio Program Management are key stakeholders and they are responsible for
delivering the business results.
4. Here the backlog contains the EPICS (Which contains many features.), EPIC owners are
responsible for driving this.
5. The main roles involved are Enterprise Architect, PPM (Program Portfolio Management),
Epic owners.
6. Events are Strategic business planning and Epic planning.
12.Do you consider 100% capacity for the team during planning? Can one team member work in
multiple scrum teams?
Considering 100% capacity for each team member will lead to overtime and Stress in the team
environment. So, it is never recommended.
Before the sprint starts, in the sprint planning meeting Scrum Master can prepare one excel
sheet containing a column of the name of each team member, any vacations planned, %
contribution for the project.
Consider a 2 weeks Sprint, 10 days and 5 people on board, the table may look like this:
The total number of
Name of the team
member
Available days for the sprint
(Vacations Planned may be or others)
%
Productivity
hours.
Per day if we work 8
hours
A
10days
75
80*.75=60 hours
B
5 days
75
40*.75=30 hours
C
10days
60
80*.6=48 hours
D
2 days
75
16*.75=12 hours
E
10 days
50
80*.5=40 hours
Total =190 hours
Going beyond 0.8 can be risky and can derail teams too.
In this sprint, the total available working hours for the team is 190 hours. The reason for asking
the productivity for the sprint is that out of 8 hours per day we need to spend on meetings,
some presentations, interviews, and Mails etc. Generally, we consider 6 hours a day of each
team in which they work to their full capacity. The why 50% or 60%? The reason could be
1. A team member might have to work on 2 projects. (Sometimes other team needs the
help of this person)
2. A team member has to spend time on technical debt for some other project also.
3. A team member is in training for a few days.
4. A team member is allocated to support maintenance activities also.
5. Ceremonies
6. Unplanned work
After arriving the figure called 190 hours the same can be filled into the Project Management
tool.
But the question may arise why hours??? Here we are calculating tasks details which are done in
a number of hours. i.e. breaking the user story into tasks.
To the question about team member working on multiple projects. Ideally “Not recommended”.
But It depends upon the situation. When doing heavy development, it is better to have a single
product. If doing lighter enhancements, multiple products can be supported.
The "rule of thumb" to address that is to work on one product until you have something to
deliver, and only at *that* point chooses whether the next deliverable thing will be from this
product or the other. Working on 2 different features at the same time delays the delivery of
both - even when for the same product. If you already know you want them both finished before
you deliver, then working in parallel is not too much of a problem; other factors than early ROI
and early feedback from having delivered, take precedence. But this rarely applies when working
on 2 different products that are very likely to have independent delivery cycles.
Keywords
Keyword
Search Volume
Agile Methodology Interview Questions and Answers
90
Agile Scrum Interview Questions and Answers
20
Basic Agile Interview Questions
10
Agile Concepts Interview Questions
10
13.Merge two arrays in JavaScript
Let’s say the following are our arrays:
[20, 40, 60]
[80, 100, 120]
To merge them, JavaScript provides the Array.concat() method. The return value of this method
is a new array with the result of concatenated arrays:
var res = arr1.concat(arr2);
Let us now merge the above two arrays:
<html>
<head>
<title>Merge JavaScript Arrays</title>
</head>
<body>
<script>
var arr1 = [20, 40, 60];
var arr2 = [80, 100, 120];
document.write("Array 1 = " + arr1);
document.write("<br>Array 2 = " + arr2 );
var res = arr1.concat(arr2);
document.write("<br>Merged Arrays = " + res );
</script>
</body>
</html>
The output displays the merged arrays:
Array 1 = 20,40,60
Array 2 = 80,100,120
Merged Arrays = 20,40,60,80,100,120
14.How do you know if you are using Agile development and that Agile is working for your
organization?
There is no standard/universal checklist to measure an organization’s successful Agile adoption.
So, every organization should develop its own set of criteria based on what matters most to
them. Some of the examples include

Development teams are better able to estimate and predict releases

Products delivered to customers feature better value proposition

The operations team has the bandwidth for more value addition

Enterprise architecture is robust but flexible

Teams participate and contribute to common corporate initiatives not directly related to
their projects

Business stakeholders actively participate in Agile ceremonies

Increase in software quality and reduced technical debt

Reduced lead time to ship validated product, and reduced cycle time for hypothesis
validation
15.Imagine you have a discussion with your friend who boasts about the recent successful
Agile adoption by his team. What key questions you may ask to look for if his team is really
being Agile?
While doing Agile is about following sets of practices, it is the Agile attitude which complements
the practices and helps the organization reap maximum benefit. So, if a team is just following a
defined set of practices without understanding the rationale behind it and not having an Agile
mindset, the team will not succeed. So, I shall ask a few questions like Has your team adapted
any of the Scrum practices to suit your team’s need? How frequently does your team release
value to its customers? Does the team hold each other accountable to sprint and project success
and are they empowered? Does the team stride to improve their technical expertise and is time
buffered for innovation? How does the team respond if there's a crisis or problem that makes a
deadline or planned milestone no longer possible to achieve?
These are just a few quick litmus tests to see if a team is being Agile and if a team is negative
on any of the above questions, then they are most definitely not there yet.
16.
Given there exists a plethora of Agile metrics, given a choice, which metrics would you want
to track and for what purpose?
Metrics in Agile can have three most important goals:

To measure how much value is being delivered to customers.

To measure effectiveness delivery to the business.

To measure a team’s health
Measuring deliverables:

Team Velocity shows how many user stories were completed by the team, on an
average, in previous sprints. It assists in estimating how much work the team is able to
accomplish in future sprints.

Escaped Defects shows how many bugs were experienced by users in production.

Sprint burn-down shows the number of hours remaining to complete the stories planned
for the current sprint, for each day during the sprint.
Measuring effectiveness:

Time to market shows the time a project takes to start providing value to customers.

ROI shows the total revenue generated from a product vs. the cost of the sprints
required to develop it.
Team’s health:

Member turnover shows how healthy the team environment is.

Team satisfaction survey shows how satisfied team members are with their work.

Sprint retrospective gives a qualitative measurement of the team’s health.
17.How would you, as a Scrum Master, estimate the impact of holidays and time-offs on your team’s
velocity?
Velocity can be a very useful predictor of how much work an Agile team can compete in the
future. In general, the impact can be ignored with the idea that history repeats itself and
that team members will probably take time off in the future at the same rate they took time off
in the past and reduced productivity balances off over a long term.
However some situations demand adjustment for holidays and team member vacations, like in a
situation when a project is of short duration, a team member is on leave for more than a normal
period, etc. In such cases, velocity is adjusted proportionately to the full team, with an
understanding that everyone can do everything. So, Predicted Velocity = Average Velocity ×
(Planned Working Days ÷ Average Working Days).
But in case if team members are not interchangeable, velocity is adjusted proportionately based
on skills.
18.What are the various planning stages in Agile?
Agile planning is iterative in nature.
Planning Stage
Description
Ownership
Frequency
Product Vision
To detail what the product is,
who will and why use it, and how
the product supports the
company’s overall strategy
Product Owner
Revised once a year
Product Roadmap
To provide a visual overview of
the high-level product
requirements, timeframes for
deliverables, prioritization and
estimations details of all releases
over time
Product Owner
Revised twice a yea
Release Plan
To describe the high-level
timeline for product releases
Product Owner
Revised twice/four times a
year
Planning Stage
Description
Ownership
Frequency
Sprint Plan
To describe sprint goals and
requirements and how those
requirements will be completed
Project Team
Revised once a sprint
Daily Scrum
To discuss on what was
completed yesterday, what will
be done today and any
roadblocks found
Project Team
Daily for 15 minutes
Sprint Review
To demonstrate the working
product/deliverable to
stakeholders for
feedback/acceptance
Project Team
Monthly, or at least for each
sprint, for an hour
Sprint Retrospective
To discuss on product and
process improvements and
picking on at least one area to
focus on continuous
improvement
Project Team
Monthly, or at least for each
sprint, for an hour
19.When to use an Agile model?
The quality of execution in any project largely depends on choosing the correct methodology. In
some cases, Agile will be an ideal option, but not always. A flexible development model should
be applied in the following cases:

The consumer needs to quickly launch the product and commercialize it.

The client is ready to regularly communicate with the team.

The team is able to adapt to new challenges and work independently.

Any changes will be made throughout the project development cycle.
The below matrix also represents where Agile works well.
20.What is a spike in Agile, its various types and when should you use them?
A Spike is a key tool used by agile teams to investigate and resolve problems as early as
possible. It is a short time-boxed exploration of an approach to reduce project risk by learning
just enough about the unknown aspect of a user story.
Although spikes can be done at any time during a project, they are generally don’t at the start of
a project, before the development effort begins.
There are two types of spikes:

Architectural spike: The idea is to explore the viability of an approach or a solution in a
short time frame.

Risk-based spike: The idea is to investigate, and possibly reduce, an issue or threat to
the project.
21.How does a development team handle risks in Scrum?
The entire Scrum team owns risk management and is responsible for mitigating it together, they
should always think about the risks that could threaten the success of the project.
Accepting only fully groomed story for a sprint, making the increment size smaller, are few
effective ways to reduce risks early in the project lifecycle. Daily stand-up (What is blocking
progress?), sprint review and retrospective are few platforms to identify and discuss risks.
When a team encounters risks, they should maintain them in a way that ensures that the status
and priority of each risk is visible and monitored. Risk burn-down chart is one such effective
graphical indicator. Depending on the impact a risk causes, some can be accepted, some just
monitored, and priority risks added to the backlog for mitigation planning.
22.What is the Agile Inverted Triangle Model?
While the traditional triangle of constraint kept Scope as fixed and Time & Cost as a variable,
the Agile Triangle of Constraints keeps Cost & Time as fixed and Scope as a variable component.
This reversal of the traditional triangle means that the agile team allows the scope to vary within
the fixed parameters of cost and time. In other words, we aim to deliver the most value we can
by X date within X budget. As knowledge work projects are characterized by experimentation
and uncertainty – and the end product can be refined forever, we need to determine acceptable
operating boundaries, which usually takes in the form of cost and time constraints. For example,
let’s say we are developing training materials for a course on agile. For a project such as this, we
could continue adding and tweaking our lesson material and exercises indefinitely. Instead, we
need to get to an acceptable performance point, and then have the discipline to stop.
23.Should we tailor the newly adopted agile methodology for our team?
Process tailoring refers to adapting our implementation of agile to better fit out project
environment.
As a general recommendation, teams that are new to agile should use their methodology “outof-the-box” for a few projects before attempting to change it. That’s because the problems a
new team encounters with a standard technique or practice should be due to their lack of skill or
experience using that technique, rather than issues with the technique itself. By discarding or
changing the practice before its value is recognized, we risk losing the benefit the practice was
originally designed to bring to the project.
In addition, the team should go through the three-step process to increase mastery and address
the appropriate time and place for agile process tailoring.
Shu: Obeying the rules – means “to keep, protect, or maintain”
Ha: Consciously moving away from the roles – “to detach or break free”
Ri: Unconsciously finding an individual path – “to go beyond transcend”
24.What do we mean by “Fail Fast” in agile?
Fail fast is a philosophy that suggests if a proof-of-concept effort isn’t successful, we can try a
different approach and if none of the approaches are successful, we cut the losses.
The principle behind it is that rather than continuing on a project that would have eventually
failed, the remaining funds and resources from the project can now be directed to other projects
that are awaiting resources.
Fail Fast principle is also applied at the software bug lifecycle. As we know, the longer it takes
for a bug to appear on the surface, the longer it takes to fix and the greater it costs.
Fail-fast makes bugs and failures appear sooner, thus:

Bugs are earlier to detect, easier to reproduce and faster to fix.

It’s faster to stabilize software.

Fewer bugs and defects will go into production, thus leading to higher-quality and more
production-ready software.

The cost of failures and bugs are reduced.
Fail-fast is the principle behind many agile practices like Test Driven Development and
Continuous Integration.