Agile Testing Interview Questions and Answers Agile Management

This is a frequently asked question in Agile testing interview questions.  

The Agile Manifesto, considered by many to be the Bible of all things Agile, lays out the foundation for Agile. It is a document that outlines the central values and principles of Agile Software development. The four core Agile values help the team to improve their work processes. They help to improve upon the old traditional process which was not efficient and was so rigid that it could not easily handle changes.

The Agile Manifesto impacts Agile testers in many ways, which are outlined below:

• Individuals and interactions over processes and tools: Testers have to work closely with customers, developers, and product owners so that they are aware of the scope and tasks that they are developing
• Working software over comprehensive documentation: Testers do not have detailed documentation/ requirements handy using which they can test against. They have to carefully pen down and refine the acceptance criteria and carry out testing with the help of Scrum teams.
• Responding to change over following a plan: Agile implements an incremental approach and responds to changes in the scope at any point in time. Testers have to prioritize and reprioritize their tests while at all times focussing on achieving the required goals of the customer.
• Collaborating with customers over contract negotiation: Agile testers have to focus on stability, security, and new features that are in line with customers’ evolving needs.

Expect to come across this popular question in Agile scenario-based interview questions.  

In simple terms, the Test-Driven Development (TDD) method focuses on formulating unit test cases before forming the real code. It is an iterative approach and combines test cases and code. 

The TDD approach derives its roots from Agile Manifesto principles and Extreme programming. It is a mode that permits developers and testers to obtain optimized code that is flexible in the long term. 

Three phases of Test-Driven Development 

1. Create specific test cases  
2. Improve the Code after each unit test 
3. Restructure the existing Code 

 Agile adopts an iterative development methodology where the scope is defined through collaboration between the customer’s needs and Scrum teams.

Organization ABC has just implemented the Agile methodology of testing. The product owner should consider some principles of the agile testing processes which are given below: 

1. Agile teams have to test continuously as it ensures progress of the product. 
2. Testing provides feedback on a regular basis and ensures that the product meets the organization’s needs. 
3. Tests are performed by the whole Agile team. The developers and business analysts also test the product or application. 
4. The business team is invited at the end of each iteration to provide feedback, and are therefore closely involved in the project progress. The team hence ensures that feedback response is on time. 
5. Defects raised by the agile team are fixed in the same iteration and this helps in keeping the code clean, simple and scalable. 
6. Agile teams use checklists that can be used iteratively. The team focuses on the test cases instead of details. 
7. In Agile methods, testing is performed during the execution and development phase whereas, in the traditional process, the testing was performed after the development phase. 

Old traditional development methodologies, such as waterfall, follow linear sequential development/ testing processes. Agile testing offers more benefits than the old traditional testing methodologies. Testing using agile methodology ensures reduction in cost and the capability of delivering products of the highest quality that are in line with end-user expectations. 

Below are the benefits of Agile testing: 

1. It ensures that testers are involved from the start of the project, are well aware of the requirements and know exactly what will be delivered in the next iteration. They are, therefore, able to prioritize their test cases and artifacts in accordance with work progress. 
2. Testing is performed alongside the development work, and products are tested during the build. This early detection rescues fatal escalations. 
3. Agile testing is product-driven and requires less documentation. Continuous deployments, and regular feedback from the client ensures quality and hence saves time and money. 
4. In this type of testing methodology, the testers have more time to write test cases as they are involved from the beginning. 
5. Testing from the beginning, regular feedback, and continuous testing ensures that product build works as per the expectations of the client. 
6. In this type of testing the fatal errors/ bugs are located early within the iterations before the product is delivered to the client, and this greatly reduces the cost of defects. 
   

Agile methodologies deploy continuous testing across iterations instead of only testing at the end, and result in products of superior quality.  

Below are different approaches to Agile testing: 

• Behavior Driven Development (BDD) 
  • In this approach, the testing is implemented on the expected behavior of the software created by the Agile team. 
• Acceptance Test-Driven Development (ATDD) 
  • In this approach, the testing is implemented on the acceptance criteria test cases created based on the communication between customers, developers, and testers. 
• Test-Driven Development (TDD):  
  • In this approach, test cases are executed before developers start writing their code.

A must-know for anyone heading into an Agile interview, this question is frequently asked in Agile testing interview questions.  

Agile is a set of practices that improve the efficiency of the software development process, teams, and organization. With the help of self-managing and cross-functional teams, high-quality solutions are delivered. 

The Agile Project Life Cycle comprises the following: 

• Sprint Planning: Sprints, which are time-boxed cycles in which a product increment of value is created, are at the core of Agile. Bigger tasks are fragmented into smaller manageable chunks or fragments. The team has to complete their tasks within the agreed timeline.  
• During the sprint planning event, the product owners, developers, testers, talk about the goals for the upcoming sprint. The team discusses their tasks, daily plan, obstacles, and impediments in daily scrum meetings. 
• Creation of Test Cases: The testing team composes the test cases as provided in the functional requirements document(FRS) and project design documents. 
• Test cases help to maintain quality and clean code. To prevent defects, documented test cases are handed over to the QA Manager and Developers for review. 
• Verification and quality validation: Maintenance of quality is very important to reduce cost. Testers create test cases and validate them to maintain quality and efficiency. 
• Product Maturity and stability: Agile is associated with iterative development. New requirements can be accepted and accommodated at any stage of the development process. It is also important to restrict requirement flow to ensure product stability. Testing teams validate the requirement changes and ensure that the product sustains stability. 
• Regression testing and continuous deployment: Manual and automated test cases are executed for each story in the sprints, as an agile development process, in order to deploy products of high quality. 

Agile testers play a very important role in maintaining the quality of the product developed. They are required to participate in project and development activities, and share their testing expertise and abilities. 

Agile Testers ensure that the following is in place: 

1. There is proper use of available testing tools 
2. Test environments and data are managed efficiently 
3. Coaching/ Mentoring other team members in aspects of testing  
4. Relevant responsibilities of testing are scheduled during the sprint release and planning. 
5. Test strategy is updated as and when required. 
6. Cooperates with developers, customers, and stakeholders in interpreting requirements 
7. Implements appropriate tests at the appropriate and right time and levels. 
8. Reports defects and works with the team in resolving them. 
9. Engages in sprint retrospective meetings proactively and suggests improvements. 

It's no surprise that this one pops up often in Agile methodology interview questions.  

The Software testing process consists of various testing procedures and techniques. All these techniques are used to simplify the processes and improve efficiency. Implementing agile testing procedures and practices ensures high-quality delivery as the bugs are detected in the initial stage before the build is delivered to the end customer.

In the current era, agile testing has gained a lot of acceptance as it provides better results in a shorter time. The test plan is written and updated at every release.

Test plan in agile includes: 

1. Scope of the testing 
2. Blending new functionalities that need to be tested 
3. Agile Testing/Levels types 
4. Load testing and performance 
5. Infrastructure 
6. Risks plan 
7. Resource planning 
8. Milestones and deliverables

Extreme programming is a software development methodology that can be used here. Its values, principles, and practices, and goals allow small to mid-sized teams to deliver high-quality software. It helps the team to adjust, and evolve to changing requirements. 

Extreme Programming includes 

1. Developing unit tests before coding. It encourages us to keep tests running at all times. The unit tests are automated and exclude defects at the beginning, thus reducing the costs. 
2. Evolve with a simple design to code the features and redesign when required. 
3. Programming in pairs (called pair programming) i.e. One of them is at the keyboard, the other regularly analyses, reviews and provides inputs. 
4. Integrating and testing system developed recursively and a number of times a day. 
5. Upgrading the product with minimal effort whenever it is required. 
6. Getting customers involved all the time and receiving continuous feedback. 

Agile testing refers to a software testing procedure in which software is checked for faults, mistakes, and other issues. It is regarded as an important aspect of the development process since it allows developers and testers to collaborate as a team, improving overall performance. It also contributes to the timely delivery of high-quality products. All the members of an agile team who have specific skills and knowledge are included in order to guarantee the timely delivery of a product with frequent releases of new features. 

Agile testing is a process that relies on agile software development concepts. It is frequently done so that testers can spot and resolve issues early on in project development. In agile testing, development, and testing happen at the same time. The tester's responsibility is to act as a developer, providing improvements, recommendations, and test cases to be incorporated in the application rather than just detecting flaws. 

Testers cover the entire product lifecycle with agile testing, but because of effective, continuous communication and regular interaction between customers and developers, the application may be provided quickly without affecting product quality. Instead of having a structured plan, the testers and developers react to sudden changes in the process and come up with quick solutions. 

There are 7 main principles of Agile Testing. These include: 

• Continuous Testing: To maintain continuous development progress, the Agile team should do testing on a regular basis. Unlike traditional techniques, which need the testing team only to focus on product testing, the Agile testing approach involves the whole team where members contribute equally in the testing process. 
• Continuous Feedback: Client feedback is often encouraged during this process to ensure that the product satisfies the customer's or client's needs. 
• Less Documentation: Rather than lengthy documentation, this approach frequently incorporates the use of reusable checklists. 
• Clean Code: The team ensures that the software is of high quality by testing it to make sure the code is simple, clean, and tight. The Agile Team swiftly fixes all mistakes and flaws discovered during the testing phase in the same iteration. 
• Team Work: Software testing or application testing can be done by not only testers but also developers and business analysts. 
• Test-Driven: Testing is done after implementation in other traditional approaches, whereas agile testing is performed during implementation so that any faults or difficulties can be addressed quickly. 
• Customer Satisfaction: During the agile testing process, customers or clients are informed of development progress so they can adjust and revise their expectations. This is done to make sure that the customer is satisfied. 

A common question in Agile testing interview questions for freshers, don't miss this one.  

The following are some examples of Agile methodologies or frameworks that are extensively used around the world for software and project development: 

• Scrum: This is a method for forming hypotheses, testing them, reflecting on the experience, and making improvements. Feedback, small teams, self-management, and work divided into sprints are all essential here. It works on a step-by-step basis. 
• FDD (Feature-Driven Development): This entails the creation of software models every two weeks, as well as the design and development of each model feature. It is essentially an incremental and iterative software development process with the goal of delivering stable and functional products on time.  
• Lean Software Development: This is a method of reducing waste and increasing value. It is primarily concerned with process efficiency in order to achieve the best results in terms of customer value. It is built entirely around two guiding principles which are continuous progress and respect for people. 
• XP (Extreme Programming): XP stands for "extreme programming." Its main goal is to build higher-quality software while also improving the development team's quality of life. It is regarded as a flexible, low-risk, and cost-effective method of developing software that assures clients receive what they desire. This methodology involves testing software from the beginning and collecting feedback in order to improve the process of development. 
• The DSDM (Dynamic Software Development Method): This is a project management methodology that focuses on the entire project lifecycle. Its fundamental goal is to establish strong governance as the basis of project management. It is user-driven and maintains that changes to the project should be expected at all times. It also includes a comprehensive plan for delivering products on budget and on time. 
• ASD (Adaptive System Development): This emphasizes the notion that projects should continually be adapting. It follows a three-part cycle that includes speculating, collaborating, and learning. 
• Crystal Methodology: Instead of procedures, this focuses on the person and their interactions. It is regarded as among the most lightweight and adaptable techniques for program development. 
• Kanban: Kanban projects are typically overseen by a board or table known as a Kanban Board. This board is a tool that allows members of the team to monitor workflow and track its progress. Its key goals are task management flexibility, continual improvement, and improved workflow. 

The Scrum Master, the Product Owner, and the Developers are the three main roles in Scrum. The three roles undertake specific responsibilities and obligations to enable teams to deliver work effectively. As the basis of Scrum is self-organization, empiricism, and continual improvement, teams take ownership of how they structure themselves and continue to improve. 

The Scrum Master is essentially the leader of the team or supervisor in charge of making sure that the Scrum team completes all of the tasks that have been assigned to them. The Scrum Master collaborates with the Scrum team to guarantee that each sprint is completed in a timely manner and that the team's workflow is in order. 

The Product Owner is essentially a project stakeholder who is in charge of managing the product backlog. He or she is also in charge of defining the team's vision and goals. The Project Owner works with customers and end-users to gather requirements that the team can use to design the best product possible. 

The Scrum Team is made up of individuals who are individually responsible for working together to achieve a certain project. It is the development team's responsibility to create genuine product increments and achieve sprint objectives. Every member of the team should be self-motivated, dedicated, and accountable for the work's high quality. 

Agile Software Development is an iterative method for developing complex software. This strategy allows project teams to become more flexible while still ensuring that the end product meets the customer's needs. It creates customer-focused products and delivers them in shorter timeframes.  

Traditional software development, on the other hand, is a method for creating simple software that follows a linear path. All parts of the process are normally carried out in this methodology in a sequential order. It is better suited to projects in which the scope of changes is limited. 

Here are some of the differences between these two approaches: 

• Agile Methodology emphasizes customer collaboration, flexibility, teamwork, and features, while Traditional Methodology emphasizes upfront planning and prioritizes aspects such as scope, cost, and time. 
• In Agile Methodology, testing is frequently done concurrently with development, while in Traditional Methodology, testing is normally done towards the end of the development process. 
• The Agile Methodology tests small features while the Traditional Methodology tests the entire application. 
• Agile Methodology involves a number of stakeholders, including customers, while Traditional Methodology does not include all stakeholders. 
• In Agile Methodology, testers and developers collaborate to achieve a common goal, while in Traditional Methodology, developers and testers work separately. 
• In Agile Methodology, customers are involved at every step of the process, while in Traditional Methodology, customers are solely involved at the requirement phase. 
• In comparison to traditional procedures, agile processes are more flexible and focused. 
• Agile Methodology is better suited to tasks that are huge or complex while Traditional Methodology is better suited to undertakings that are tiny and simple. 

One of the most frequently posed Agile testing interview questions, be ready for it.  

Yes, the Agile methodology has some limitations, some of which are as follows: 

• Poor resource planning. Predicting the amount of effort required to finish a task is difficult. It becomes even more challenging in the case of huge projects because it is difficult to estimate the overall effort necessary. 
• It's not always possible to devote enough time and attention to the project's design and documentation. 
• There is a scarcity of documentation. Documentation occurs throughout an Agile project and is frequently "just in time" for generating the output rather than from the start. As a result, it gets less detailed and frequently falls to the bottom of the priority list. 
• The output is fragmented. Incremental delivery may help get goods to market quicker, but it's also a major drawback of Agile. This is because when teams are working on distinct components in different cycles, the final product is often fragmented rather than a single entity. 
• There is no conclusion in sight. It's easy to get side-tracked offering new, unanticipated functionality because Agile needs less planning at the start. Furthermore, because there is never a clear idea of what the "finished result" looks like, projects have no clear end. 
• The final project may not meet the customer's expectations if the client's requirements are not well grasped. As a result, the customer will be dissatisfied. 
• Only a leader with extensive knowledge of Agile methodology is capable of making critical judgments. Members of the team with minimal or no experience do not participate in decision-making and hence do not have the opportunity to expand their knowledge. 
• Measurement is difficult. Because Agile works in chunks, tracking progress necessitates looking over multiple cycles. As a result, you won't be able to specify many KPIs at the start of the project. 

The advantages of the Agile process include: 

• Conversations with team members and consumers are on a one-on-one basis 
• Gives attention to good design and technical excellence. 
• Continuous development allows for client and project team engagement and interaction, ensuring and promoting customer happiness. 
• Customer or end-user feedback is received more quickly. 
• Errors in the code are quickly identified and eliminated. 
• Agile projects are divided into sprints or iterations, which are short and repeatable phases that last between one and four weeks. 
• It is simple to manage and gives you additional options. 
• Agile is good for projects with an undefined goal that becomes clearer as the project continues. 
• The process involves all stakeholders such as testers, clients, and developers, and leads to the technical proficiency and great design. 
• Its adaptability ensures that it can adjust to changing conditions. Changes made at the last minute or at a subsequent development stage can be easily implemented. 

The disadvantages of using the Agile process include: 

• There is a scarcity of formal design and documentation. 
• Estimating resource requirements and effort is difficult. 
• It's not ideal for small-scale development initiatives. 
• In comparison to other development approaches, it is more expensive. 
• It will take more time and effort from everyone. 
• There is the danger of the project never ending, as new requirements keep getting added. 
• Major projects are difficult to scale. 
• Testing and test construction are difficult. 
• Whenever software deliverables are vast, determining the effort level necessary at the start of the software development lifecycle can be difficult. 
• Experience and seniority are required for critical decision-making in the product development process. As a result, freshers have a difficult time finding a position in the agile software development process. 

Re-factoring refers to a process that involves changing or modifying the internal structure of software without affecting its external functionality or behavior. Developers alter the code or experiment with it in order to enhance and improve the software's underlying structure. Red-Green refactoring is among the most popular and commonly used refactoring strategies in agile software development.

The refactoring process improves the readability, understandability, and cleanliness of the code. Refactoring on a regular basis makes it easier to expand and maintain code. The purpose of software development is to provide users and stakeholders with commercial value on a constant basis. It is challenging to retain and continually grow business value because technology is continuously changing, and corporate objectives are changing as well.

There are two possible future paths which include continuing to add new capabilities to a pre-existing code base, eventually resulting in an error-prone "throw-away" condition or modifying the system on a regular basis to ensure that it is capable of efficiently delivering not only present but also future business value.

Refactoring, the second option, is preferable. The usable life of an enterprise's software assets can be stretched out as long as necessary with continual refactoring. This means that customers can continue to get a value stream for years ahead. Refactors allow for an emergent design to guarantee that the system meets future business requirements.

The Product Backlog is an important list of items that includes everything that needs to be included in the final product. It consists of all of the Development Team's ideas, as well as the requirements of the Stakeholders, Product Owners, and others. 

It serves as a source of prerequisites for product adjustments that must be made. Because all Sprint Backlogs are sourced from Product Backlogs, they can be regarded a subset of Product Backlogs. The Scrum process adds features and updates to the product in Sprints. 

Here are the differences between these two backlogs: 

• The product backlog is a list of all the tasks that must be done before the final product may be created. The sprint backlog, on the other hand, is a list of all the items from the Product Backlog that must be done in order for the Sprint to be completed. Also included is a strategy for converting the selected elements to an Increment. 
• The Product Owner has the responsibility of gathering, prioritizing, and refining the Product Backlog items. On the other hand, the Development Team is in charge of developing the Sprint Backlog and working on it in order to finish the Sprint on time. 
• The Product Backlog is dedicated to the product's overall goal while the Sprint Backlog solely pertains to the Sprint goal for that Sprint. 
• Depending on the customer's vision, there may be opportunities to alter the product backlog. On the other hand, the Sprint Goal will not change throughout the Sprint, but the Sprint Backlog may change depending on the Sprint. 
• The Product Backlog is the entire collection or list of tasks that must be accomplished in order to fully develop the product. The Sprint Backlog is a subset of the Product Backlog that gets finished in a Sprint. 
• The Product catalog has nothing to do with the Sprint Backlog, whereas the Product Backlog is the sole determinant of the Sprint Backlog. 

A staple in Agile testing interview questions for freshers, be prepared to answer this one.  

The "Just in Time Production" philosophy is followed by the lean software development process. Its goal is to speed up software development while lowering costs. Lean is based on the principle of reducing non-value-added processes while increasing customer value. The agile process is a lean software development lifecycle method in and of itself. 

Backlog grooming and code refactoring, on the other hand, suit agile approach better with lean concepts. Backlog grooming is the process of ensuring that the right items are in the backlog, that they are properly prioritized, and that those at the front of the backlog are ready to be delivered. In summary, the Lean methodology dictates that everything that does not provide value must be eliminated. 

Removing waste entails not just the elimination of ineffective working methods like multitasking, but also the elimination of unnecessary tasks, meetings, and documentation. Here are some change concepts as a result of lean methodology: 

• Demand should drive production rather than supply. It is a matter of doing something once someone asks for it instead of first doing it and then hoping that it will be needed by someone later. 
• In order to take advantage of economies of scale, production should be done in small batches. 
• Taking the time to concentrate on quality also boosts output and efficiency. 
• Employers, and not managers, are in charge of determining how employees will work. 
• Rather than simply repeating predefined duties, workers must constantly improve their working methods, in a process known as "Kaizen". 

This question is a regular feature in Agile methodology interview questions, be ready to tackle it.  

Listed below are the good qualities that an Agile tester should possess.  

1. Positive attitude and solution-oriented  
2. Focused on achieving the goals fixed  
3. Excellent communication skills   
4. Skills to understand the customer requirements 
5. Basic knowledge of the Agile process and methodologies  
6. Critical and creative thinking skills 
7. Ability to share new ideas  
8. Ability to plan and prioritize work as per requirement  
9. Flexible enough to cope with any change 

Kanban is a well-known framework for Agile and DevOps software development. This is a tool that assists the team in keeping a careful tab on the task and determining its development. Kanban necessitates real-time capacity communication and complete work transparency. On a Kanban board, work items are visually depicted, enabling members of the team to see the status of each piece of work at any moment. 

The Kanban board allows you to have the entire project scenario in one spot, giving you a clear image of the bottlenecks, completed tasks, and progress of the workflow. It enables the team to deliver a product on a consistent basis without being overburdened. Visualizing procedures and decision-making guidelines will aid in the proper execution of tasks and make it possible for different teams to discover and specify process changes. In addition, all project teams will be able to track their progress in real-time and select what to concentrate on first and what to undertake next. 

Kanban methods first found acceptance in the manufacturing sector and have since been proven to drive success in Agile software development organizations. This methodology has just recently begun to be recognized by companies across diverse industries. Kanban strives to create a service-oriented mindset. It necessitates a deep understanding of your customer’s demands, the creation of a range of services where individuals self-organize around the task, and the continual evolution of your system. 

Pair programming refers to a practice in agile software development where two programmers work together in one workspace to enhance efficiency. One programmer develops the code as the other observes reviews it. The two programmers regularly switch duties. 

There are a number of benefits of taking this approach. These include: 

• More effective. Rather than having two programmers work independently on two different projects, you effectively combine their efforts to create a single application. 
• There are less code errors. It results in better code since another programmer is reviewing your work. It enables one programmer to concentrate on the code being written as the other attends to other concerns. 
• A good approach to convey information. It is an approach that enables programmers to receive immediate face-to-face coaching, which would be far superior to online tutorials and quicker than searching the Internet for information. Highly advanced programmers could also teach developers best practices and improved methodologies. It can also help two programmers form mentoring ties. 
• Improves the interpersonal abilities of your employees. Working together on a single project teaches your team the importance of teamwork and communication. 

There are some drawbacks of taking this approach which include: 

• During a paired session, both programmers have to always be actively engaged with the project. If this does not happen, no gain will be achieved. 
• The stakes are higher if both programmers miss an error during the programming process. 
• Relationship issues between the programmers may become a hindrance to pairing successfully. 

This is a frequently asked question in Agile software testing interview questions.  

Scrum of Scrums refers to a scalable agile technique for connecting several teams that need to collaborate to produce complex solutions. Whenever there are numerous teams working on a project, this term is used. It relates to the daily Scrum meeting's scalability. Every team is in charge of running and leading its own Scrum meeting in this case. 

Nevertheless, in order to maintain communication and coordination amongst all the multiple teams, a separate meeting with all of the teams needs to be held. This is what the "Scrum of Scrums" is all about. It enables teams to design and deliver complicated products at scale by facilitating openness, inspection, and adaptation. 

It is most successful when all effective Scrum team members work towards one goal, trust and respect each other, and are fully aligned. The bigger the number of lines of communication between members of the team, the more difficult it is to build trust and a single goal. As a result, dividing a big group into two or three smaller groups can aid in the development of interpersonal relations and the achievement of desired results. 

Coordination is required when many teams are formed to achieve a common goal. This is what necessitated the creation of Scrum of Scrums. Scrum of Scrums teams not only coordinate delivery but also ensure that a completely integrated product is delivered at the end of each sprint. As a result, Scrum of Scrums serves as a release team responsible for delivering value to clients. This strategy is generally used as a first step in scaling Agile and organizing delivery of larger and more complicated products. 

Agile refers to a development methodology that takes an iterative and incremental development approach. Scrum, on the other hand, is the most popular Agile framework in use by organizations worldwide. In Scrum, the customer receives incremental builds every 2 to 3 weeks.  

Here are the differences between the two:  

• Agile software development is thought to be best suited to situations with a small but highly skilled project development team, while Scrum is best suited for projects with quickly changing requirements. 
• Leadership is extremely important in the Agile process, while Scrum encourages a cross-functional team that is also self-organizing. 
• Agile is a more rigid method when compared to Scrum. As a result, there isn't a lot of room for regular modifications. Scrum's greatest benefit is its adaptability since it reacts fast to changes. 
• Agile entails cross-functional collaboration and person-to-person interactions between members of the team. Collaboration is accomplished in Scrum by holding daily stand-up meetings in which the scrum master, product owner, and team members each have a specific role to play. 
• Agile development may necessitate a significant amount of up-front systems and organizational modification. When implementing the Scrum process, however, there aren't many adjustments that need to be made. 
• The agile process necessitates regular delivery of the product to the end-user for feedback. On the other hand, after every Scrum sprint, a build is sent to the client for review and feedback. 
• All through the Agile lifecycle, every step of development, including requirements, analysis, and design, is continuously monitored. On the other hand, at the end of each sprint in Scrum, a demonstration of the functionality is given so that comments can be collected on a frequent basis before the next sprint. 
• In the agile technique, the project leader is in charge of all tasks. Because there is no team leader in Scrum, the difficulties or problems are addressed by the entire team. 
• The design and implementation should be kept as simple as possible in Agile, while experimental and innovative design and execution are possible in Scrum. 
• The most basic indicator of progress in Agile is working software, whereas in Scrum, working software is not a basic criterion. 

Agile testing quadrants represent a helpful taxonomy to help agile teams to identify, plan and execute the testing and ensure that all resources are available to accomplish it. 

• Quadrant Q1 - Unit level supports the developers. Developers perform unit testing and these tests can also be automatized  
• Quadrant Q2 - It is to test the whole system with business processes and other systems. 
• Quadrant Q3 − User Acceptance Level and focus on real-time scenarios. These tests are performed manually. User Acceptance Tests belong to this quadrant.  
• Quadrant Q4 − Operational Acceptance Level. Focus on Performance, Load, etc. Specialized instruments can be utilized for these tests along with automation testing.

Expect to come across this popular question in Agile testing interview questions.  

Refactoring improves the internal structure of the program source code without changing its internal behavior. 

Pitfalls 

Refactoring would not mean

1. Writing code again 
2. Fixing bugs 
3. Developing noticeable features of software such as its interface. 

Benefits of refactoring: 

1. Refactoring accommodates characteristics of length, duplication, coupling and adherence, and complexity so that it can be easily maintained 
2. Refactoring helps to understand the code in a better way 
3. It encourages developers to understand design decisions in the context of collective and code 
4. It promotes reusable design elements and code modules 

The Product Backlog contains an essential list of items that are necessary for integrating into the product. Sprint backlogs are considered to be the subset of the product backlogs. As the sprint backlog is derived from the product backlog. 

Following are the differences between the Product Backlog and Sprint Backlog 

Expect to come across this popular question in interview questions on Agile testing.  

Velocity predicts how much work can be completed by the development team within a two-week sprint. It is useful for estimating how fast and how long the team will take to complete a project.  

The velocity is calculated by reviewing the work that the team has successfully completed during the previous 3 weeks. If the team completes 10 stories during the 2-week sprint and each story has 2 story points, then the team velocity is 30 points. 

Calculate Velocity 

Example to calculate velocity in Agile: 

• Sprint 1, Team committed to complete eight stories. Each story equals three-story points. The team could complete only four stories. Achieved story points are 12. 
• Sprint 1, Team committed to complete 10 stories. Each story equals five story points. The team could complete only 7 stories. Achieved story points are 35. 
• Sprint 3, Team committed to complete 9 stories. Each story equals four story points. The team could complete only 7 stories. Achieved story points are 28. 

Average sprint velocity = (12+35+28)/3 = 56 

This question is a regular feature in Agile interview questions, be ready to tackle it.  

Sprint zero alias inception phase takes place before the start of the project. The goal of the inception phase or sprint zero is that the team comes together to develop minimal user stories, project skeleton, and to develop a workable product. The sprint must be lightweight.

Purposes of Sprint Zero 

The purpose of this Sprint is to be productive. The Sprint should remain a lightweight exercise. By the completion of this Sprint prioritization of features or a list of Users, Stories should be completed.  

Sprint zero purposes 

1. Create a useful piece of code. 
2. Minimal conditions for writing code. 
3. Prioritization of features or stories. 
4. Release plan detailing each story to a Sprint. 
5. Plan for the implementation of features. 

A staple in Agile testing interview questions for experienced, be prepared to answer this one.  

The goals of Backlog Refinement are as below: 

1. Backlog refinement with the team helps to share and analyze the requirement properly, to avoid wrong execution, exhausting effort, and reworking the implementation to get it finished. 
2. Backlog refining helps in sizing the items and hence saves us from risk and overrating and underrating costs. 
3. It helps us prioritize the backlog. Prioritizing saves us from working on unimportant items. 
4. It improves the efficiency of Sprint planning meetings as most of the risks, queries are already discussed.
5. It helps in keeping the backlog clean, relevant, and focused on goals 
6. It leverages the benefits of detailing the stories and hence helps the development team during the development phase.
7. It enhances understanding between the Scrum Master and stakeholders.

A burndown chart represents how quickly the team is working on the customer user stories. The burndown chart depicts total effort against the amount of the work for each iteration 

The burndown is a chart that explains how the team is burning customers’ user stories. It shows the total effort versus the amount of work we deliver for each iteration. 

The above graph gives us: 

1. Work completed against each iteration 
2. Work remaining for each iteration 
3. Work done so far for each iteration 
4. When can we expect the work to be completed 

Burndowns provide information as below: 

1. Provides clarity on the project  
2. Provides information on the impact of decisions taken 
3. If the project is delayed then the chart warns us, so that the team can implement workarounds for impediments 
4. Warns you early if things aren't going according to plan. 

A common question in interview questions on Agile Scrum testing, don't miss this one.  

Step 1: Create a table with the data to plot the burndown chart 

It is required to have three columns 

1. Calendar 
2. Estimate 
3. Actual 

• Column A: Calendar 

Column A indicates time frame of sprint or task.  

• Column B: Estimate 

Column B would have number estimates of tasks/activities that are pending to be completed each day.  

• Column C: Actual 

Column C would have estimates of actual work that is remaining to be completed each day. 

The burndown charts can be created in Excel by using above data.  

One of the most frequently posed Agile methodology interview questions, be ready for it.  

Burn-up charts are project management tools that visually represent the scope of a project or iteration (i.e., sprint). It represents the work that has been completed so far in the development process.

Two lines can be seen on the chart. 

1. The blue line represents the amount of work that has been completed  
2. The orange line represents the total amount of work required to reach the goal to complete the sprint.

Burn-up and burndown charts are the two types of charts which track the progress of the projects. A burndown chart shows how much work is remaining and burn-up chart shows how much work is completed. These charts are collectively used in Agile projects. 

The burndown chart shows the team did not accomplish much in the project but could finish all the tasks in the end. The burn-up chart indicates that the scope increased in the beginning and some scope was removed to meet the deadline of the project. The team then made steady progress throughout the project.  

Agile Scrum methodology is used for the below reasons: 

1. When the requirements are not clear. The client is confused and has no clarity on the business case. 
2. Client expects quicker release than the competitor, and late release may lose the advantage of MVP. 
3. Client is not clear with the requirements and doesn't have clarity, or a vision for the product. 

Sprint Definition: 

Acording to Atlassian, a sprint is a ‘short, time-boxed period when a scrum team works to complete a set amount of work’. The sprint term refers to accomplishing the goals within a predefined boxed time. The period of a sprint is usually short i.e., one or two weeks, and represents a timeboxed iteration of a continuous development cycle. The work in the sprint is planned and the team has to work to accomplish the goals and make it ready for review. Sprints are broken into small chunks of duration, and are no longer than 3-4 weeks.

An Epic is a series of user stories that share a broader strategy. Several epics share a common goal and are grouped together under a business objective called as a theme. User story can be completed within the timeframe of a sprint, but an epic will typically require development work covering several sprints. 

The Epic sits between Theme and Story in agile development. The theme represents a high-level strategy for its product. Themes are broken into several epics by the team and then epics are broken down into several user stories. A story represents a small unit of development work that will allow the user to complete the goals. 

A User story is a brief explanation of a feature written from the user’s point of view. Agile experts describe a user story as the smallest unit of product development work.  

User stories are the unit of development work designed to accomplish a specific goal within a product. A user story is written within the user’s perspective and follows the format: “As [a user persona], I want [to perform this action] so that [I can accomplish this goal].” 

The Product team breaks the development work into user stories for several reasons: 

User stories: 

1. They are easy for anyone to understand 
2. User stories can fit in sprints whereas full features can’t 
3. User stories help the team to create and progress well in the creation of the MVP.

Definition of Task: 

User stories represent work broken down into single units, called tasks, that are usually completed by one person. 

Use of Tasks: 

Tasks are small increments of work to be completed during a sprint. The team creates tasks on post-it notes and puts them on up their Agile task board. 

Tasks Benefits: 

1. User stories are broken into small manageable units 
2. Team members complete the tasks without feeling overwhelmed 
3. They can easily identify the tasks created on the task board 

In the iterative process, progress is made through successive refinement of tasks. The development team creates/ develops the first cut and the team then iteratively improves parts until the full product is created satisfactorily. The customer’s feedback is taken after each iteration and then the software is enhanced in greater detail.  

Let us take an example of search functionality on a website. For the first iteration, a simplistic search screen can be developed. In the next iteration, advanced search models would be added.  

An incremental method entails producing components of the software in parts. Each increment outlines a complete subset of functionality and is entirely coded and tested. 

For example, in an e-commerce store, initially, payment can be supported only via credit and debit cards. In the subsequent release, payment via wallets can be established and supported. 

Sprint Zero is the iteration where the team get prepared for the project execution.  

Sprint Zero is used for the following reasons. 

1. Collecting servers or hardware resources for the project 
2. Constructing the team 
3. Elaborating the primary backlog items 
4. Creating Application Architecture design 

A Spike is a task aimed at clarifying a question or collecting information, rather than at designing a shippable product. A spike is created to handle the task further after collecting relevant information and hence it can be estimated correctly. 

Spikes are time-boxed activities that have precise goals and desired results. This technique enables delivery teams to determine how to deliver a working product efficiently. 

Spikes can be of three types: 

• Functional: Inspects story by decomposing it and identifies risks 
• Technical: Defines the impact of a story or task to understand the technical necessary design. 
• Exploratory: Explores organizational impacts for a particular story. 

The principal roles are

• Scrum team: The Scrum team constitutes of people who work collectively to achieve the best outcome for any given task. The product is created by a dedicated Scrum team.
• Scrum Master: The Scrum Master is the individual who is responsible for the proper working of the entire team. The Scrum Master is a leader and a coach. It is his or her responsibility to assure that the team operates at their best, being productive and meeting the end sprint goal. Scrum Masters are leaders and facilitators who remove any impediments in the way of progress and smoothen the workflows.
• Product owner: The duties of the product owner involve the delivery of a comprehensive and lucid picture of the product. He or she also conveys the same idea to the team.

An Impediment keeps the team away from getting work done and this slows down the velocity.  

Impediments appear in various forms: 

1. Technical debt 
2. Bad boss 
3. Individuals who don’t understand agile  
4. A hurricane 
5. Power outage 
6. Lack of understanding of automated testing 
7. The matrix organization 
8. Team working on more than one release at the same time 
9. The insufficient skill of the team 
10. Unresolved technical issues 
11. Lack of DBA skills within the Team 
12. Need to refactor the Architecture 
13. Technical impediments 
14. Blockers to particular stories 
15. Organizational impediments 
16. Resource issues 

An accidental error by a software developer that seldom stops the build process, or causes unacceptable warnings in the automated test environments, is known as a "Build Breaker".  

Continuous integration is an important characteristic of products developed through agile methodology. Developers sometimes make mistakes and accidentally commit flaws to the software repository. When such commits stop the build/compile process or cause unacceptable warnings or failures in the automated test environment, the build is said to be broken. The developer is assumed to have committed a build breaker.

User acceptance testing (UAT) is the last phase of development in which software users test the software to ensure that it can handle required tasks in real-world scenarios.  It is also identified as beta testing, application testing, or end-user testing. 

User Acceptance Testing (UAT) in Agile practices  

1. Planning 

A plan describing all aspects of the UAT is pulled up. 

2. Test cases designing 

Test cases are designed to cover all the functional scenarios of the software in real-world usage.  

3. Selection of testing team 

Testing team made up of real-world end-users is created. 

4. Documenting test cases and execution 

The team executes test cases, bugs and comments are logged. 

5. Bug fixing 

The software development team fixes the listed bugs. 

6. Sign-off 

The testing team accepts the software application, which indicates that the application suffices user requirements and is equipped to be rolled out in the market. 

A tracer bullet is a spike that is part of the production code. It would be executed within the current architecture and technology that is established along with the best practices that are within the current project development. It is of production quality code and the rest of the iterations are built on this code. This is the most important aspect as other developers will be using this same code to work on the next iterations or enhance new features. 

For example 

In the E-commerce platform, a new service is developed. Let's name this service as ProductCountService. Now, this could be a tracer bullet as this service would be used by other developers to extend working on a similar sort of feature development task where they need to enhance the features. All the enhancements should adhere to code quality and best practices and the unit tests should be properly written and passed. 

The build-breaker is a condition that occurs when there is a defect in the software. This results in a sudden unanticipated bug; the compilation process freezes or execution fails or a warning is caused. The duty of the tester is then to get the software back to the healthy working stage and it is the onus of the developer to resolve the bug and make this build normal, as soon as possible.  

The daily stand-up is for sharing the daily status among all the members of an agile team. This forum helps to address and mitigate problems that the members face. It is a mandatory practice regardless of whether the teams are collocated or not. 

What is Daily Stand-up? 

• The daily stand-up is held among all team members and is roughly for 15 minutes. 
• Each member has to answer three important questions 
  • What did I do yesterday? 
  • What will I do today? 
  • Any impediment I am facing and any solutions. 
• The daily stand-up is for status update only not for team discussions. Members should schedule meetings at a different time if they need to discuss issues. 

Importance of Stand-up Meeting 

Following are the benefits of having stand-up meetings 

1. The agile team can evaluate the progress and can commit to actions, as required, for each iteration 
2. Each team member informs the others about their commitments and everyone is aware of the same 
3. It provides visibility to the team if there are any changes in the schedule or any delays.  

Stand-up meeting Audience 

1. Scrum Master, Product Owner, and the Delivery team should attend the meeting 
2. Stakeholders and Customers can attend in the meeting as observers 
3. Scrum Master has the responsibility of taking notes and noting down queries of each team member. 

Sprint Review Meeting aka Sprint Demonstration is usually held on the last day of the sprint. It is held to demonstrate the product increment to stakeholders and the team. The Product Owner reviews the finished stories and marks them as Done or Not Done based on “Definition of Done”.  

The audience of the Sprint Review Meeting  

Scrum Team, the stakeholders, Business Sponsors and Management participate, and the objective of the meeting is to showcase the sprint increment to the audience of the sprint review meeting. 

Stakeholders, Business Sponsors, Management Participates are not fixed participants.  

The Product Owner Invites the stakeholders in advance. The Scrum Master facilitates the meeting, schedules it in advance, and sets the scope. The Key recipients can take a decision on how important it is for them to attend the meeting and may choose to opt out when not required. 

The Development Team demonstrates the stories one by one as planned. The order can be changed on the Product Owner's request or on the key meeting recipient's request. 

The Stakeholders evaluate the increments. They accept increment(s), recommend new changes for the future sprints, or can also repudiate the increment that is to be deployed. 

The sprint retrospective is held at the end of a sprint to review what went well during the previous sprint and what can be improved for the next sprint. 

Purpose of a sprint retrospective 

The sprint retrospective is a timeboxed meeting that is held after the sprint review and before sprint planning for the next iteration. 

The sprint retrospective meeting helps in the below ways: 

To examine how the previous spring completed went and what can be done to improve the deliveries in the next sprint. 

1. Identify and prioritize the tasks that went well. 
2. Identify and prioritize the tasks that didn’t go well. 
3. Identify possible amendments. 

Scrum retrospective helps Scrum team members to classify how they can improve to contribute better to the sprint. The team would ask questions themselves like what work has been done well in this sprint? What work hasn’t been done well? What should we start doing to improve? The development team then focuses on improving quality by improving work processes or adapting the definition of “done.”  

Sprint Retrospective Audience 

It usually includes development team members, the Scrum Master, and the product owner. The Scrum Master conducts the meeting and assists the development team to enhance its workflow practices within the process framework for the next sprint.  

Stakeholders and managers who are not directly part of the team usually don’t come to a Scrum retrospective unless they are invited. They engage in the sprint review meeting where the scrum team reveals what they have achieved and accomplished during the sprint through product demos. 

Definition 

Sprint planning is an event where the team handles the product backlog items, that they will work on through that sprint. The team chalks out their initial plan for completing those product backlog items. They establish sprint goals and, on that basis, they determine on which product backlog items they would work to complete their goals. 

Sprint Planning Audience 

Sprint planning involves the entire team. 

A product owner proposes the product backlog items and their priorities to meet the sprint goals. The team determines how many items they would be able to complete and how they would deliver. The Scrum Master ensures that there is consensus on the sprint goal, and appropriate product backlog items are included in the sprint backlog. 

Sprint Planning venue 

Sprint planning is held in the team room so that it is easy to access all the information about your product backlog. If the team is distributed, sprint planning serves as a great opportunity to gather all distributed team members, so that the discussions would be more effective and strengthen connections among the team. 

When does Sprint Planning take place? 

Sprint planning occurs on the first day of a new sprint. 

The event should occur after the sprint review and retrospective meeting so that any output from these meetings can be considered while planning for the new sprint. 

Scrum ceremonies are vital ingredients of the agile and software delivery methodology process. These ceremonies implement the framework for teams to get work done in a structured way, aid to anchor expectations, authorize the team to cooperate effectively, and eventually prompt results. If these meetings are not managed appropriately, they can overwhelm calendars and kill the value they are expected to contribute. Often when teams quit certain ceremonies, it’s because they don’t see the advantage in them anymore. 

These are the five key scrum ceremonies: 

1. Backlog grooming (product backlog refinement) 
2. Sprint planning 
3. Daily scrum 
4. Sprint review 
5. Sprint retrospective 

The metrics should be a combination of project-related metrics, as well as business metrics that help to view the progress of the team.  

Here’s a list of the most important metrics: 

1. Sprint Burndown 

The burndown chart is a graphical illustration of the predicted Scrum tasks as compared to the actual tasks completed. The volume of work left is plotted versus time for the duration of the sprint. The output in the duration of hours, story point, or backlogs remaining can be calculated which enables tracking the real-time progress of the sprint.  

2. Lead Time 

Lead time is the duration of receipt of the requirement and its successful delivery. This includes the time duration from the actual commencement of the development process to the end of delivery.  

Lead time and cycle time are popular Lean and Kanban metrics that help to identify potential bottlenecks within the process. It also provides stakeholders and clients necessary insights about the estimated velocity of development. 

If the lead time is low, then the requirement moves faster from the backlog to the development phase, and this then lowers the cycle time and hastens the development process. 

3. Flow Diagram 

Cumulative flow is an essential Kanban metric for assuring a steady flow of work across the team. The cumulative flow diagram provides information for bottlenecks at any stage and is instantly envisioned and the work in progress is more easily tracked. 

The intricacies can be tracked on a real-time basis during the process. The problem resolution and analysis take place instantly. 

4. Sprint Velocity 

Velocity is a measure of the amount of work the development team is able to perform in a given period of time. Velocity is an important metric; but it is relative and cannot be used as a measure of competence or performance of the agile team.  

5. Failed Deployments 

Failed or unsuccessful deployments are the deployments that fail to get pushed over a given period of time. These failed deployments can be calculated over a week, month or depending on the recurrence of your releases. 

6. Code Coverage 

Code coverage aka test coverage provides a much-needed view of the amount of untested code in your codebase. It is not a measure of how good your tests are but gives a rough visualization of the code that is incorporated by unit tests. 

7. Net Promoter Score 

NPS is a business metric that represents the likeliness of your customers to refer to their contacts. Customer analysis and collection of feedback are crucial in the calculation of the Net promoter score. 

A Scrum of Scrums meeting is to manage large projects with varied teams. A Scrum of Scrums is held to assist interaction among teams that may have dependencies on one another. After the daily stand-up meeting, one member from all teams attends the Scrum of Scrums to represent his/her team to manage or handle questions or concerns of the team. 

In case of teams working on a large project with dependencies, risks, or issues that could impact another team’s sprint goal, a Scrum of Scrums is scheduled to discuss or resolve these issues. 

Following are the Benefits of Scrum of Scrums: 

1. Expedites communication and collaboration within the teams. 
2. Multiple teams can view the bigger picture of the project and how sprints would affect the teams. 
3. Depreciates the risk of the team's work which is negatively impacting each other. 
4. Addresses problems of teams and makes course corrections, if essential. 
5. Optimizes the workflow within the project. 

Automation testing is encouraged for testing on Agile projects because of the following reasons: 

1. Agile methodology encourages Incremental Development. Agile teams have only a few weeks to gather requirements, implement code changes and test the changes. If everything has to be done manually then teams may fall short on deadlines. 
2. Agile projects do not have the complete set of requirements up front. The requirements elaborate with time and often change depending on customer priorities, market trends etc. If everything has to be done manually then teams may fall short on deadlines. 
3. Agility demands early and continuous testing. Agile testing stretches to the newly added code, and code from previous iterations as this ensures prior functionality is not disrupted due to the recently added functionality. Testers face lots of pressure and this can affect the quality of the product. Automating testing will allow testers to have more time in hand for exploratory testing. 
4. Automation testing allows testing the code quickly with a conventional suite of test scripts. This gives the tester more time to react in case the code is not up to expectations. 
5. Automation in testing allows automating other testing activities like data set up, test result validation, and creation of test reports. Frequent code deployments can be automated and this allows testers to focus more on testing. 
6. Automation testing allows detailed and exhaustive examination of the code. This ensures code quality. 

Agile estimations are relative estimations that allow teams to procure more information about the items. All estimations are done in relative units, usually in story points. 

Agile estimation techniques are as below: 

Planning Poker 

All members use numbered playing cards and estimate the tasks that need to be done to achieve the goals. Voting is done anonymously, and discussions are held when there are large differences. When the whole team reaches consensus, voting is stopped.  

T-Shirt Sizes 

This is a perfect system for estimating a large backlog of large items. Items are estimated into t-shirt sizes: XS, S, M, L, XL. The determination about the size is based on open and mutual collaborative discussion.  

Dot Voting 

A relatively simple and effective technique to estimate a small set of items using Dot Voting. This method originated from decision-making and can be used for estimating. Each person receives a small number of stickers and can decide how to vote for the items.  

The Bucket System 

A faster method than Planning Poker is the Bucket System. This system is a good option when it is used to estimate a large number of items, and the team has a large group of members. The group estimates the items by laying them in these “buckets”. A bucket is usually represented by a sheet of brown paper on which you can place sticky notes with the item names.  

Large/Uncertain/Small 

A fast method for rough estimating is the Large/Uncertain/Small method. The initial step is to classify the items into two extreme categories, and then place the mid-sized items between them. It is a simpler version of the bucket system. This system is better for use within smaller groups with comparable items. 

Affinity Mapping 

This system is based on discovering associations in the estimated items. The team groups the items together in small groups to large groups. It works best with a small group of people and a relatively small number of items. 

Ordering method 

This is a practice to get an exact image of the relative size of items. All items are set in random order on a scale number varying from low to high. Every participant moves from one item on the scale. Each move is just one spot lower or one spot higher or to just pass on the turn. The ordering protocol is a process of arranging the items in fine-grained size estimates. It works best with a relatively small group of people and a large number of items. 

MVP 

The minimum viable product (MVP), as formerly defined by Eric Ries, allows testing an idea by exhibiting an initial version of the product to the target users and customers, collecting the appropriate data, and learning from it.  

For instance, to examine the viability of using an Artificial intelligent Paywall product as the major revenue source, an early product version can be released to measure if and how often people use the product. We can view the MVP as a risk reduction tool as it will provide data of consumer behaviour using which it can be enhanced to have a full-proof product. MVP is about learning, and it’s no surprise that it plays a key part in Lean Start-up's build-measure-learn cycle.

MMP 
The Minimal Marketable Product encourages creating a minimal offering of the product in the market. It includes the smallest possible feature set that meets the needs of the initial users. The MMP is a tool to lessen time-to-market launch. Designing a product with just the right amount of features sounds like common sense.  

An example of an MMP is Apple’s original iPhone launched in 2007. The first iPhone was a complex product and the phone did provide just a few features. To determine the right features, the aforementioned MVP is a fantastic tool. 

A Scrum Master works with the product owner and the Scrum team to refine and improve processes where it makes sense. 

A Scrum Master has the following roles and responsibilities 

Coach team members 

The Scrum Master ensures that team members are well trained and have experience in Agile processes. The Scrum Master takes utmost care that the team members have a sense of project ownership and that teams are self-managed. 

Host daily stand-up meetings 

Daily Scrum, or stand-up, meetings last for 15 minutes. Each team member gets the opportunity to answer these questions: 

1. What did you do yesterday? 
2. What will you do today? 
3. Any issues and impediments 

Helps product owner with the product backlog 

The product owner is accountable for creating and maintaining the product backlog. The product backlog is a list of items that the agile team would work on to achieve the goals defined. The Scrum Master helps the product owner to refine the product backlog with the information gathered from daily stand-up meetings. 

Remove roadblocks 

The Scrum Master protects the team from distractions and roadblocks that can impede progress. 

For example, if team members are dragged into many unimportant meetings, the Scrum Master intervenes and determines who really needs to attend the meetings.  

Practices and principles 

To assure that work is not slowed down, the Scrum Master acts as a mentor and teacher to placidly onboard new employees or team members. The Scrum Master also helps new team members to understand the scope of a product and ensures that newly joined team members understand and adhere to Scrum practices and rules. 

To calculate velocity, we will use story points to measure the amount of work completed in each sprint.  

Step 1: Calculate how many user story points are achieved in each sprint 

In sprint 1: 

A team committed to achieving/ completing 6 user stories. 

Each user story had eight-story points, making a total commitment of 48 story points. 

The team completed three of the six user stories. 

In sprint 2: 

The team this time committed to eight user stories (including three user stories from the sprint 1). 

User stories had eight-story points, making a total commitment of 64 story points. 

This time team completed five out of the eight user stories. 

In sprint 3: 

The team again committed to nine user stories. 

Each user story had ten-story points, making a total commitment of 80 story points. 

The team was able to complete seven of the ten user stories. 

Step 2: Average calculation of completed story points 

Add the total of story points completed, then divide by the number of sprints. 

1. Sprint 1: 3 user stories x 8 story points = 24 
2. Sprint 2: 5 user stories x 8 story points = 40 
3. Sprint 3: 7 user stories x 8 story points = 56 

Total = 120 

Average sprint velocity is 120 ÷ 3 = 40. 

The amount of work that can be completed in future sprints on an average is 40 story points. If there are in total 192 story points remaining to be completed, it can be assumed that the team would require approximately 4 more sprints to complete the user stories in the project. 

The product roadmap is a high-level summary that charts out the vision and direction of the product that we are developing over time. A product roadmap describes why and what is getting built and it is a plan for executing the product strategy. 

The product roadmap is created to achieve goals as below: 

1. Defines the concept and strategy 
2. Provides a guiding document for accomplishing the strategic goal 
3. It helps the internal stakeholders to be aligned 
4. Expedites discussion of opportunities and scenario planning 
5. Helps in communicating with external stakeholders, including customers 

Product RoadMap contents include 

1. Theme 
2. Epic 
3. User Stories 
4. Tasks 

A Sprint can be cancelled before the Sprint time-box is accomplished. The Product Owner has the authority to cancel the Sprint, and the product owner may do so after consultations with the stakeholders, the Development Team, or the Scrum Master. 

Following are the reasons that a Product owner Might Cancel a Sprint: 

1. A better technical solution is observed that makes the current technical solution outdated. 
2. A major change in technology. 
3. Market forces the current work as obsolete. 
4. Primary and critical external changes refute the Sprint Goal or the Product Goal 

Story Maps were initially introduced by Jeff Patton in 2005. The principal idea behind Story Maps is that single-list product backlogs are very difficult to organize and prioritize A need for richer structure arose and hence the story map concept was introduced. A story mapping is a compelling device that facilitates an agile team to refine their product backlog and design the product releases more efficiently. 

Few benefits of using a story map: 

1. Handle backlog with a summary and straightened structure 
2. Brainstorm, review, and prioritize user requirements in a collaborative path 
3. Control activities and responsibilities and distribute them into epics or user stories in an orderly manner 
4. Classify and prioritize user actions and user tasks, or dig down to improve them into relevant epics or user stories 
5. Maintain user stories online for both remote and co-location environments

Scope creep—It is an inclination for software projects to extend beyond their original bounds. Avoiding scope creep improves the chance of delivering the project on time and within budget. Smaller projects have a greater chance of success; hence this is the reason that a large assignment is split into smaller components. 

Below are the 8 tips to prevent scope creep from taking over your project 

1. To be careful from day one 
2. Clearly understand the requirements and vision of the client 
3. Understand and gather the project requirements 
4. Introduce a system of changing the scope 
5. Watch and guard against gold plating 
6. Always use online project management software for efficient handling of all the processes 
7. Always be careful and know when to say no 
8. If we can’t say no to the customer who is loyal find out some other alternatives 

The Definition of Done generates clarity by granting everyone a shared perception of what work was completed or developed as a component of the Increment. If a Product Backlog item does not satisfy the Definition of Done, it cannot be published or even inferred at the Sprint Review meeting with stakeholders, customers, etc. Alternatively, it reverts back to the Product Backlog for future deliberation.  

A servant leader is a servant first. The purpose of this concept is to improve and enhance teamwork, individual responsibility and accountability. 

A servant leader is one who 

1. Builds trust 
2. Empowers team 
3. Supports and encourages them to achieve the next level 
4. Is ethical and caring 
5. Is humble and socially aware 

He or she ensures that the team is getting together well, understands the team needs, understands the business objectives, and thereby works towards the common goal. The Scrum Master smoothens impediments, and irons out any conflicts that may arise within the team. 

The concept of servant leadership is all about  

1. Assisting people/ team 
2. Listening to grievances of team 
3. Spending time with the team, to train and inspire them 
4. Politely drawing out their mistakes and helping them improve  

In the Scrum agile framework, the Definition of Ready outlines the elements that must be answered in sequence for a story to move from the backlog to development. Ready is often interpreted as a story that can be portrayed instantly.  

Typical items considered for a definition of ready: 

• Actionable – Actionable item i.e. (doable) by the team? The team should be aware of what they require to do, and can they do it now?  
• Refined – Item within a process of refinement before sprint planning. The team should have a common understanding of what the item is and how it would be completed? 
• Value – The business value of the item and what is the value to the end-user? The team should have a clear vision of the value of the item that would be developed 
• Estimated – Item estimated by the team and the item accepted to be of a size that the team is comfortable that it can be completed within the timebox of a sprint 
• Acceptance criteria – Item that has got clear acceptance criteria 
• Demo – Team understands how they would demo the item or present it in the sprint review once concluded? 

Scrumban is an Agile development methodology that is a combination of Scrum and Kanban. 

Scrumban was developed to meet the requirements of teams who wanted to reduce the batching of work and embrace a pull-based method. A mixture of Scrum and Kanban provides teams the versatility to accommodate stakeholder and production requirements without getting overburdened by their project methodology.  

Scrumban renders the edifice of Scrum with the versatility and visualization of Kanban, delivering a highly adaptable path to workflow management.  Scrumban can be used as a steppingstone for teams attempting to transition from Scrum to Kanban. An immediate shift to Kanban would be futile to developers and scrumban allows teams to learn a process of how to practice perpetual development and improvement in Kanban without dropping the common structure of Scrum. 

Agile uses empiricism in order to adjust to the dynamic requirements of the customer. Empiricism is the act of addressing and making decisions based on what is really experienced. The empirical strategy works in a fact-based, experience-based, and evidence-based manner, and development is based on measurements of truth or reality and not fictitious plans. 

The three pillars that support the implementation of empirical process control are  

• Transparency: Transparency can be achieved by tools such as Product Backlog, Task Boards, Burndown charts, Daily Stand-ups, Retrospectives, Definition of Done, Sprint Reviews, etc. It allows visibility with regards to the progress of work and team 
• Inspection: The artifacts must be regularly examined and progress towards a purpose or goal should be detected to avoid undesirable variances. 
• Adaptation: It always embraces and Adapts variations or changes to constantly improve. Adaptation implies to have changes that does not work or what could work better. 

Following are the ways to be dealt with the discord 

1. The problem’s origin or the root cause demands to be recognized/ identified and addressed 
2. Full control should be established 
3. Disperse the difference and disagreement  
4. Spotlight on areas that complement the project 
5. The common agreement requires to be authorized to guide the team 
6. Performing, continuous monitoring, and providing complete visibility to the team is very important 

The principal purpose of an Agile Product Owner is to serve the customer to the development team.  

Product Owner Responsibilities include: 

1. Managing and creating an evident and visible product backlog. The product owner then prioritizes a list of specifications for prospective and future product development. 
2. Swapping the order of items in the product backlog. 
3. Conveniently available to the development team at any time to answer every question that team members have concerning the customer’s needs and views of how the team is completing a product feature. 

 The Product Owner Role is an indispensable and essential member of any agile team. 

The sprint burndown chart bestows the progress the development team is executing. It is a powerful tool for envisioning progress and the work remaining.  

The chart displays: 

1. The outstanding work on the first vertical axis 
2. Time, in days, along the horizontal axis 

The Burndown chart allows anyone to view the state of the sprint at any time. Comparing the realistic number of hours available to the actual work remaining depicts the effort that is being planned is in better health than demanded or is in trouble. This information helps to determine about the development team is able to accomplish the targeted amount of user stories and assists in making knowledgeable decisions early in the sprint. 

Sashimi is a Japanese word that means a pierced body. It is a Japanese food that consists of fresh meat or fish, sliced into small and thin pieces. Every part is similar in taste when associated with the other pieces.

Sashimi in agile methodology implies that each stage of the software development cycle in a sprint entails requirement analysis, planning & design, development, testing, documentation that is completed or not and the product is available and ready to be displayed, etc.

The daily scrum is a 15-minute time-boxed meeting that is held at the same time, in the same place, each working day. The objective of the daily scrum meeting is to present an opportunity to outline the work for the next 24-hours remove any impediments that might hinder it from achieving the sprint or product goal. 

To banish confusion or chaos and keep things productive as much as possible, daily Scrum meetings are held at the same time and same place every day.

Development teams are structured and authorized to establish and control their individual work. It helps to optimize overall efficiency and effectiveness.

Great development teams have the following features: 

1. Development teams are self-organizing and no one teaches them how to turn product backlog into Increments conceivably releasable functional products. 
2. Teams have all the abilities and skills that are necessary to create a product increment 
3. Individual team members may have specialized abilities and areas of focus, but responsibility or accountability belongs to the development team as a whole. 

A Development Team is a group of individuals working collectively to develop and deliver the product increments. The development team includes software engineers, architects, programmers, analysts, system admins, QA experts, testers, UI designers, etc. 

Following are the roles and responsibilities of the development team: 

The Development Team builds the product and the team is cross-functional 

1. The team has all the expertise essential to deliver the potentially shippable product of each Sprint 
2. They are self-organizing, with a high degree of independence and accountability. 
3. They decide and plan out items to be built in a Sprint. 
4. They are a cross-functional and self-organizing team that owns the mutual accountability of generating, creating, testing, and delivering the product increment. 
5. The team doesn’t have any manager to lead since decisions are taken collectively by the development team.