SCRUM - It is used in teams that need to handle constant changing requirements

What is Scrum?
Answer: Scrum is an agile framework for managing and organizing work, that helps teams develop
and deliver high-quality products iteratively and incrementally. Scrum is based on principles of
transparency, inspection, and adaptation.
Key components of Scrum include:

1. Roles:
 Product Owner: Represents the customer or stakeholder and is responsible for
defining the features and priorities of the product.
 Scrum Master: Facilitates the Scrum process, removes impediments, and ensures
that the team follows Scrum practices.
 Development Team: A cross-functional group of individuals responsible for
delivering the product incrementally.
2. Artifacts:
 Product Backlog: A prioritized list of features, enhancements, and fixes that
represents the requirements for the product.
 Sprint Backlog: A subset of the Product Backlog selected for a specific sprint,
representing the work to be done during that iteration.
 Increment: The sum of all completed items from the Product Backlog at the end of a
sprint.
 3. Events:
 Sprint: A time-boxed iteration typically lasting two to four weeks, during which a
potentially shippable product increment is created.
 Sprint Planning: A meeting at the beginning of each sprint where the team plans the
work to be done during that sprint.
 Daily Scrum: A brief daily meeting for the team to discuss progress, plan for the day,
and identify any impediments.
 Sprint Review: A meeting at the end of a sprint to review and demonstrate the
completed work to stakeholders.
 Sprint Retrospective: A meeting at the end of a sprint where the team reflects on
their performance and identifies areas for improvement.
4. Scrum Values:
 Commitment: Each team member commits to delivering their best work, and the
team commits to achieving their sprint goals.
 Courage: The Scrum team has the courage to question the status quo and adapt as
necessary to meet their goals.
 Focus: The team focuses on completing the planned work during the sprint and
avoids distractions.
 Openness: All team members are encouraged to be open and transparent about
their work and challenges.
 Respect: Team members respect each other's expertise and contributions.

What are the Scrum values?

The five Scrum values—commitment, focus, openness, respect, and courage—are what drive Scrum’s
success. The values make Scrum more than just a series of processes, and are a large part of what sets
it apart from more traditional project management approaches like Waterfa

What is Product Owner?

A Product Owner is a key role in the Scrum framework, responsible for representing the interests of
stakeholders and ensuring that the Scrum Team delivers maximum value to the business or end-
users. The Product Owner plays a crucial role in defining and prioritizing the product backlog, making
decisions on what features or items should be included in each sprint, and providing guidance to the
development team throughout the development process.

What are the limitations of Scrum?

While Scrum is a widely adopted and successful agile framework, it has its limitations and may not be
suitable for every project or organization. Some of the limitations include:

1. Not Suitable for All Projects:

 Scrum is primarily designed for projects with rapidly changing requirements and a
need for frequent releases. It may not be the best fit for projects with well-defined
and stable requirements, where a more predictive approach like the Waterfall model
might be more appropriate.
2. Dependency on Team Collaboration:
  Scrum heavily relies on collaboration within the team. If there are communication
issues or a lack of teamwork, the effectiveness of Scrum can be compromised.
3. Limited in Large Scale:
 While Scrum can be scaled for larger projects using frameworks like SAFe (Scaled
Agile Framework), LeSS (Large Scale Scrum), or Nexus, managing very large projects
or organizations with hundreds or thousands of team members can still be
challenging.
4. Emphasis on Time-Boxing:
 The time-boxed nature of sprints can sometimes lead to incomplete features being
delivered if the team doesn't estimate accurately or if unexpected issues arise during
the sprint.
5. Lack of Emphasis on Technical Practices:
 Scrum provides a framework for project management but does not prescribe specific
technical practices. This can be a limitation in environments where a focus on
engineering practices, such as continuous integration, automated testing, and code
reviews, is crucial for success.
6. Product Owner Availability:
 The effectiveness of Scrum depends on the active involvement and availability of a
dedicated Product Owner. If the Product Owner is not available or lacks the
necessary decision-making authority, it can impede the progress of the team.
7. Not a Complete Solution:
 Scrum is a framework for project management, not a complete solution. Teams need
to supplement it with other practices and tools for requirements management,
testing, and continuous integration to create a comprehensive development process.
8. Potential for Scope Creep:
 Due to its adaptive nature, Scrum can be susceptible to scope creep if not managed
effectively. Changes in requirements during a sprint can impact the sprint goal and
potentially lead to incomplete work.
9. Learning Curve:
 Implementing Scrum requires a cultural shift and a learning curve for team
members, stakeholders, and the organization as a whole. Resistance to change or
lack of training can hinder successful adoption.

What is Agile Testing?

Answer: Agile Testing is a practice that a QA follows in a dynamic environment where testing
requirements keep changing according to customer needs. It is done parallel to the development
activity where the testing team receives frequent small codes from the development team for
testing.

What is the difference between burn-up and burn-down charts?

Answer: Burn-up and burn-down charts are used to keep track of the progress of the project.
Burn-up charts represent how much work has been completed in any project whereas Burn-down
chart represents the remaining work in a project.

Define the roles in Scrum?

Answer:
There are mainly three roles that a Scrum team have:
1. Project Owner has the responsibility of managing the product backlog. Works with
end-users and customers and provides proper requirements to the team to build the
proper product.
 2. Scrum Master works with the scrum team to make sure each sprint gets completed
on time. Scrum master ensures proper workflow for the team.
3. Scrum Team: Each member of the team should be self-organized, dedicated and
responsible for the high quality of the work.

What is Product Backlog & Sprint Backlog?

Answer: The Product backlog is maintained by the project owner which contains every feature and
requirement of the product.
Sprint backlog can be treated as the subset of product backlog which contains features and
requirements related to that particular sprint only.

What is Re-factoring?
Answer: Modification of the code without changing its functionality to improve the performance is
called Re-factoring.

How do you deal when requirements change frequently?

Answer: This question is to test the analytical capability of the candidate.
The answer can be: Work with PO to understand the exact requirement to update test cases. Also,
understand the risk of changing the requirement. Apart from this, one should be able to write a
generic test plan and test cases. Don’t go for the automation until requirements are finalized.

What is the difference between Epic, User stories & Tasks?

Answer:
User Stories: It defines the actual business requirement. Generally created by the business owner.
Task: To accomplish the business requirements development team create tasks.
Epic: A group of related user stories is called an Epic.

How did you handle a mistake that was made in Sprint?

1. Acknowledge the Mistake:

 The first step is to acknowledge and admit the mistake openly. In a transparent and
collaborative environment, it's important for team members to feel comfortable
acknowledging errors without fear of blame.
2. Understand the Impact:
 Evaluate the impact of the mistake on the current Sprint goal, the product
increment, and overall project timelines. Understanding the consequences helps in
devising an appropriate response.
3. Communicate Transparently:
 Communicate the mistake and its impact to the entire Scrum Team, including the
Product Owner, Scrum Master, and development team members. Transparency is a
key principle in Scrum, and open communication fosters a culture of continuous
improvement.
4. Identify Root Causes:
 Conduct a retrospective or root cause analysis to identify why the mistake occurred.
This involves looking beyond the immediate issue to understand the underlying
factors or processes that contributed to the error.
5. Implement Corrective Actions:
 Once the root causes are identified, work on implementing corrective actions. This
could involve process improvements, additional training, or changes in team
practices to prevent similar mistakes in the future.
 6. Adjust the Sprint Plan:
 If the mistake has affected the Sprint goal, the team may need to adjust the Sprint
plan. This could involve reprioritizing work, renegotiating commitments, or making
other adjustments to ensure the team can still deliver value by the end of the Sprint.
7. Learn and Iterate:
 Use the mistake as a learning opportunity. Encourage the team to reflect on what
went wrong, why it happened, and how similar issues can be avoided in the future.
The retrospective meeting at the end of each Sprint is an ideal forum for discussing
and learning from mistakes.
8. Continuous Improvement:
 Embrace a culture of continuous improvement. Encourage the team to share
insights, propose improvements, and implement changes that enhance the overall
development process.
9. Support and Encourage Team Members:
 Mistakes are part of the learning process. Provide support to team members who
may be directly or indirectly affected by the mistake. Foster a positive environment
where individuals feel comfortable learning and growing from their experiences.

A Sprint Refinement session, also known as Backlog Refinement or Sprint Planning, is a crucial event
in the Scrum framework where the Scrum Team collaboratively reviews and refines the Product
Backlog. Here's what typically happens during a Sprint Refinement session:

1. Preparation: Before the session, the Product Owner usually ensures that the Product
Backlog is up-to-date and prioritized. They also identify the items that are likely to be
worked on in the upcoming Sprint.

2. Scheduling: The Scrum Master schedules the Refinement session, ensuring that all necessary
team members can attend. This is often done shortly before the next Sprint Planning
meeting.

3. Discussion of Backlog Items: During the session, the team reviews the top items on the
Product Backlog. This includes discussing the user stories or tasks, acceptance criteria,
dependencies, and any questions or concerns team members may have.

4. Estimation: The team may estimate the effort required to complete each backlog item using
techniques like Planning Poker or relative sizing. This helps the team understand the size and
complexity of the work involved.

5. Splitting User Stories: If any backlog items are too large or complex, the team may
collaborate to break them down into smaller, more manageable user stories or tasks.

6. Acceptance Criteria: The team clarifies and refines the acceptance criteria for each backlog
item to ensure a shared understanding of what constitutes a complete and satisfactory
deliverable.

7. Dependency Identification: Team members identify any dependencies between backlog

items or with external factors that may impact their ability to complete the work.
 8. Re-prioritization: Based on the discussions and estimations, the team may suggest changes
to the prioritization of backlog items. The Product Owner makes the final decisions regarding
the priority order.

9. Documentation: Any decisions, changes, or new information resulting from the refinement
session are documented to ensure transparency and alignment within the team.

10. Next Steps: The team may identify any follow-up actions or preparations needed before the
upcoming Sprint Planning meeting.

Overall, the Sprint Refinement session aims to ensure that the Product Backlog is well-understood,
properly refined, and ready for selection during the Sprint Planning meeting.

Scrum Master Role:

1. Facilitator: The Scrum Master acts as a facilitator for the Scrum team, ensuring that all
Scrum events (such as Sprint Planning, Daily Standups, Sprint Review, and Sprint
Retrospective) are conducted effectively. They facilitate communication and collaboration
within the team.

2. Servant Leader: A Scrum Master is a servant leader who serves the team by removing
impediments that hinder the team's progress. They support the team in achieving their goals
and help them become self-organized and cross-functional.

3. Coach: The Scrum Master coaches the team in Scrum practices, principles, and values. They
guide the team in understanding and implementing Scrum artifacts, roles, and ceremonies
effectively.

4. Metrics and Progress Tracking: Scrum Masters help the team track progress towards Sprint
goals and monitor key metrics such as velocity and burndown charts. They provide visibility
into the team's progress and help identify areas for improvement.

5. Continuous Improvement: Scrum Masters facilitate regular retrospectives to help the team
reflect on their processes and identify areas for improvement. They encourage
experimentation and adaptation to drive continuous improvement.

What is ‘Scrum of Scrums’?

In the Scrum framework, each team works independently in short iterations (sprints) to deliver
incremental pieces of functionality. However, when multiple teams are involved, coordination and
synchronization become crucial to ensure alignment and integration of their work.

The Scrum of Scrums is a meeting where representatives from each Scrum team come together to
discuss progress, dependencies, and impediments. Typically, these representatives are Scrum
Masters or team leads who act as liaisons between their respective teams and the larger group.
During the Scrum of Scrums meeting, the representatives provide updates on their team's progress,
share any dependencies or blockers they are facing, and collaborate on resolving issues that span
across multiple teams. It's an opportunity for teams to align their efforts, identify and address inter-
team dependencies, and ensure that the overall project objectives are being met.

what is product increment in a sprint?

1. Completed Work: The product increment includes all the
user stories, features, or tasks that the development team
has finished during the sprint. These items should meet the
team's definition of done, which typically includes criteria
such as being fully implemented, tested, and potentially
releasable.
2. Potentially Shippable: The product increment should be in
a state where it could theoretically be released to users or
customers if the product owner decides to do so. This
doesn't necessarily mean that the product increment will be
released after every sprint, but rather that it is of high
enough quality to be released if desired.
3. Incremental Development: Each sprint builds upon the
previous ones, adding new functionality or improvements to
the product. Over time, these increments contribute to the
overall development of the product, allowing it to evolve
iteratively based on feedback and changing requirements.
4. Feedback and Validation: By delivering a product
increment at the end of each sprint, stakeholders have the
opportunity to provide feedback and validate the direction of
the project. This feedback loop is essential for ensuring that
the product meets the needs of its users and stakeholders.

Overall, the product increment is a tangible outcome of the sprint

that demonstrates the progress made by the development team
and provides stakeholders with a clear understanding of the state
of the product.

key skills of a Scrum Master?

The role of a Scrum Master is crucial in facilitating the Scrum framework within a team. Key skills
required for a Scrum Master include:

1. Facilitation Skills: The ability to facilitate meetings effectively, including daily stand-ups,
sprint planning, sprint reviews, and retrospectives. A Scrum Master should ensure that these
meetings are productive and focused.

2. Coaching and Mentoring: Helping team members understand and implement Scrum
principles and practices. This involves coaching individuals and the team on self-
organization, cross-functionality, collaboration, and continuous improvement.
 3. Servant Leadership: Acting as a servant leader by focusing on the needs of the team
members, facilitating their growth and development, and removing impediments that hinder
their progress.

4. Conflict Resolution: Addressing conflicts within the team and promoting healthy
communication and collaboration. A Scrum Master should be adept at resolving conflicts in a
constructive manner to maintain team cohesion.

5. Empathy and Emotional Intelligence: Understanding the perspectives and emotions of team
members and stakeholders. Empathy helps in building trust and rapport within the team,
fostering a positive and supportive environment.

6. Knowledge of Agile and Scrum Principles: A thorough understanding of Agile principles and
the Scrum framework is essential for guiding the team through the Scrum process and
ensuring adherence to Agile values.

7. Communication Skills: Clear and effective communication is essential for a Scrum Master to
convey information, facilitate discussions, and ensure alignment among team members,
stakeholders, and other relevant parties.

8. Problem-Solving Skills: Proactively identifying and addressing issues and impediments that
arise during the project. A Scrum Master should be resourceful in finding solutions and
implementing changes to improve team productivity and delivery.

9. Adaptability: The ability to adapt to changing requirements, priorities, and circumstances. A

Scrum Master should be flexible and responsive to evolving project needs while maintaining
focus on the overarching goals.

10. Metrics and Feedback: Utilizing metrics and feedback to assess team performance, identify
areas for improvement, and make data-driven decisions. This includes monitoring progress
through burndown charts, velocity, and other relevant metrics.

Overall, a successful Scrum Master is a servant leader who facilitates collaboration, fosters a culture
of continuous improvement, and empowers the team to deliver high-quality products effectively.

1. Burndown Chart:

 A burndown chart illustrates the amount of work remaining in a sprint or project

over time.
 The vertical axis typically represents the amount of work remaining (e.g., user
stories, story points, tasks), while the horizontal axis represents time (e.g., days of
the sprint).
 The ideal burndown line is drawn from the total amount of work planned for the
sprint to zero work remaining by the end of the sprint.
 As the team completes work, the actual remaining work is plotted on the chart.
Ideally, this line should trend towards the ideal burndown line. Deviations from the
ideal line indicate potential issues or changes in scope.
 Burndown charts help teams visualize progress, identify trends, and make
adjustments to meet sprint goals.
What is Definition of Done (DoD)?

Definition of Done (DoD) is a checklist of items that need to be completed to

declare a project or task as ‘Done.’ The checklist includes written codes,
comments on coding, unit tests, integration testing, design documents, and
release notes.
In Scrum, the "Definition of Done" (DoD) is a shared understanding within the Scrum Team, including
the Product Owner, Scrum Master, and Development Team, about what it means for a product
increment to be considered complete and potentially releasable. It serves as a quality standard that
all work items, such as user stories or tasks, must meet before they can be considered done.

The Definition of Done is unique to each Scrum Team and project and is typically agreed upon during
the early stages of a project or during Sprint Planning. It helps ensure that everyone involved in the
project has a clear understanding of the expectations for each increment of work and prevents
misunderstandings about what constitutes "done."

The Definition of Done typically includes criteria related to various aspects of the work, such as:

1. Functional completeness: The implemented functionality meets the acceptance criteria and
user requirements.
2. Code quality: The code adheres to coding standards, is well-documented, and is
maintainable.
3. Testing: The code has been adequately tested, including unit tests, integration tests, and
acceptance tests.
4. Documentation: Any necessary documentation, such as user manuals, release notes, or
technical documentation, has been completed.
5. Review and approval: The work has been reviewed and approved by relevant stakeholders,
such as the Product Owner or customer.

How can you coordinate between multiple teams?

 One of the most common approaches for this is the Scrum of Scrums (SoS) meeting,
where members representing each scrum team discuss the progress, performance,
issues, risks, etc. together.
  The frequency of these meetings must be pre-defined. Generally, scrum masters would
represent a particular scrum team, besides having the Chief Scrum Master (whose
responsibility is coordination & collaboration among all the scrums) who facilitates these
meetings.

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.

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.

Name the 5 phases of risk management.

The 5 phases of risk management are as follows-

 Risk identification - The primary step is to identify the organization's

risks in its routine operating environment. The risks include regulation,
environmental, legal, and market risks.
  Risk analysis - After identifying risks, it is critical to evaluate the
damage they can cause. You should also study the association between
the risk and the intrinsic components. It is mandatory to identify the
danger of the risk and its effect on the business operations.

 Risk in order of severity - Risks that are ranked can be easily

neutralized. Risk management solutions cater to risks that are ranked
from high to low.

 Solving the risk - A risk is still a threat until its solved and eliminated.
Risk specialists are consulted to eliminate the risk. This means regular
meetings with the concerned stakeholders till it is no longer a threat.

 Risk review - the risk is reviewed to ensure that it is completely

removed.

What is the structure of a good story?

The structure of a good story is as follows:

1. Who are we building it for, and who are the users? - As a <type of
user>

2. What are we building, and what is the intention? -I want <some goal or
objective >

3. Why are we building it, and what value does it bring for the user.? - So
that <benefit, value>

Well-formed stories will meet the criteria of Bill Wake's INVEST acronym:

1. Independent - Does your story have the potential to be stand-alone?

2. Negotiable - Your story should have the scope to make adjustments.

3. Valuable - There has to be some takeaway for users or customers.

4. Estimable - The team should be able to use it for planning.

 5. Small - Longer stories take more time to plan and implement. Keep your
story short.

6. Testable - Can you test the story?

In Scrum, what do you mean by user stories?

What benefits come from using them?

A user story is an informal, generic description of a software feature

written from the end user's perspective. Its purpose is to explain how a
software feature could benefit the customer. Putting people first is a
critical element of agile software development, and a user story
accomplishes this by putting end-users at the center of the discussion.

What is the distinction between MVP and MMP?

Minimum Viable Product (MVP) is the prototype of a product with basic

features released in the market so that early customers can use and provide
critical feedback on the product. Minimum Marketable Product is the functional
software that is ready for monetization. It consists of all the minimum essential
features. It is ready to be launched in the market. It saves you the time of
building the whole product with all functionalities. You can give the customers
what they want.
what is your current quality engineering
approach to ensure quality?
Measuring quality engineering
Measuring the effectiveness of Quality Engineering is essential to
understand how well your processes are working and to identify areas for
improvement. Here are some key metrics and measurement approaches
for QE effectiveness:

 Defect Density - this metric calculates the number of defects per unit
of code (e.g., defects per thousand lines of code). A lower defect
density indicates higher quality.

 Test Coverage - test coverage measures the percentage of your

code that has been tested. It helps identify areas of the application
that lack proper testing and might be more prone to defects.

 Mean Time to Detect and Resolve Issues - this metric tracks the
time it takes to identify a defect and the time it takes to resolve it.
Faster detection and resolution times are indicative of a more
effective QE process.

 Customer Satisfaction - survey customers or gather feedback to

gauge their satisfaction with your software. High levels of satisfaction
are a sign of a successful QE process.

 Cost of Quality - analyze the costs associated with maintaining

quality. This includes the cost of testing, defect resolution, and the
impact of defects on the business. Lowering the cost of quality
signifies effective QE practices.
  Release Stability - monitor the stability of your releases by tracking the
number of critical defects reported post-release. A stable product is a
testament to effective QE.

 Regression Test Pass Rate - measure the percentage of regression

tests that pass without any failures. A high pass rate indicates that
changes are not introducing new defects.

what is your quality audit and SQA process?

Key aspects of a Software Audit plan include:

 Objective evaluation: Conducting an impartial assessment

of software projects or processes to determine their
compliance with standards, regulations, and organizational
policies.
 Identification of weaknesses and risks: Identifying
areas where the software project or development process
may be lacking, such as security vulnerabilities, quality
gaps, or non-compliance with industry standards.
 Compliance verification: Ensuring that the software
development adheres to legal, regulatory, and contractual
requirements.
 Recommendations and corrective actions: Providing
recommendations for improvement and suggesting
corrective actions to address identified issues and enhance
overall software quality.
The primary goal of SQA is to improve the development process
and deliver high-quality software that meets user requirements
and expectations.
Key aspects of Software Quality Assurance include:

 Defining quality standards and processes: Establishing

guidelines, standards, and best practices that outline how
software development should be carried out to achieve
quality objectives.
 Quality planning: Developing a comprehensive strategy
for quality management, including defining quality goals,
identifying quality assurance activities, and allocating
resources.
  Quality control: Implementing processes and techniques to
monitor and evaluate software quality during development,
such as code review, software testing process, and
performance analysis.
 Process improvement: Continuously analyzing and
refining development processes to enhance efficiency,
effectiveness, and quality.

STORY POINTS:

Efforts required to convert the Product Backlog Item (PBI) to a working product is called a story point.

Team Velocity: Team velocity is the average number of story

points completed by the team in previous sprints. It serves as a
guideline for how much work the team can typically handle in a
sprint. The team can use its velocity to determine how many story
points to commit to in a sprint planning session.
Committed & Completed story points should be displayed in
Velocity chart