In this post, we’ve brought you top Agile interview questions to educate, learn, practice, and prepare. We aim to make you understand Agile as the methodology and how does it work, what are its principles, who all are part of it, what are the best practices, tools, and techniques to make the most from this method.

If you are a software engineer, then despite being you are working as a developer or a tester, you should read these Agile interview questions. It is a process which doesn’t divide based on the task you are performing. It enforces collaboration, supports interchanging roles to increase productivity. The theme of Agile methodology is to induce trust, encourage teamwork and get the work done.

Now, get on reading the most important Agile interview questions for both the development and testing.

50 Agile Interview Questions for Development and Testing

First of all, let’s check out a few core Agile interview questions for development and testing.

Q-1. How will you explain the Agile methodology to a layperson?


Agile is a continuous software development methodology that is quite popular these days. It focuses on the ability to the changing needs quickly and at the same time implementing it with ease.

Agile method splits the product development work into small increments called ‘Sprints’ or Iteration. Each of these Sprints is of short time duration, which typically lasts from one to four weeks.

Each iteration involves planning, coding, and testing. Towards the end of each iteration, the team gives a demonstration of the working product to the stakeholders. This practice minimizes the overall risk and allows for rapid delivery of high-quality software.

There are different agile methods like SCRUM, Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal, and Lean Software Development (LSD). Among these Scrum and XP are the most widely used methodologies.

Q-2. What do you know about the Agile Manifesto and its Principles?


Agile Manifesto is the outcome of the frustration that crept into the minds of business leaders due to the issues that surfaced from the time lag between the requirements gathering and actual delivery of the product. The Agile Manifesto constitutes four foundational values and supporting principles which drive the Agile approach to software development.

Agile methodology preaches the following 12 principles –

Agile Principles

  1. Customer Satisfaction via prompt delivery of working software.
  2. Adapt to the changing requirements for the benefit of the customer.
  3. Deliver frequent releases of working software to the customer. Plan every deliverable in shortest possible time, maybe weeks.
  4. There should be close coordination between the developers and the business people for the entire duration of the project.
  5. Projects need motivated people. Trust them by providing the support they need.
  6. Face-to-face discussion is the best mode of communication with the team.
  7. Working software reflects the current state of the project.
  8. Agile processes promote sustainable development. Developers should be capable of maintaining a uniform pace.
  9. Consistent efforts to be made to achieve technical excellence and robust design.
  10. Add simplicity by filtering out the things that do not add value. Focus on the most needed features to avoid unnecessary work.
  11. Self-organized teams usually create the best designs.
  12. The group adapts to the changes regularly.

These principles outline the core values of the Agile methodology defined in the Agile manifesto.

Agile Values

– Individuals and interactions over Processes and tools:

It is the team that takes care of business needs and drive the development process.

– Working software over Comprehensive documentation:

Agile prefers the working software over the comprehensive documentation. It works on a notion that the customer would like to see a feature running than just showing documents to them in the meetings.

– Customer collaboration over Contract negotiation:

Agile promotes collaboration with the customer throughout the development process, making it easier to meet their needs.

– Responding to change over following a plan:

Agile, focusses on quick response to change and continuous development.

Q-3. What are the advantages of using Agile Methodology?


Agile offers the following advantages-

  • In Agile methodology, the delivery of software is continuous and quick.
  • The customers are satisfied because after every Sprint a working software with some new feature is demonstrated to them.
  • Customers take a look of the working software regularly. It helps to ensure that the product is going as per their expectations.
  • If the Customer suggests any change in the feature, the team can plan to accommodate it in the current sprint.
  • In Agile methodology, it is necessary to have a daily interaction between the business people and the developers.
  • Agile allows accommodating changes in the requirements even at the later stages of the development.
  • Reduces rework as the project remains in-tune with customer needs at every step.

Q-4. What are the potential drawbacks of Agile methodology?


Like other development approaches, Agile may have drawbacks for some products and teams.

• Anticipates High Level of Commitment:

The agile model works well only when the whole development team is committed to the project for the entire duration. It may become challenging if multiple releases are happening concurrently. An individual team member may also find it difficult to cope with the rapid development.

• A probability for Escalation of Cost and Deadline:

It may be due to change, or addition of some new requirement towards the end of the Sprint. Despite, high-level of planning, it is always possible that some deliverables may not get completed on time due to some unidentified issues. It’s a bare truth of all projects. Addition of Sprints may be required to handle these, which means an increase in cost to the customer.

• Communication

Agile requires a high level of collaboration between the Customer and the team, which promotes a high level of interaction. For customers and the development teams that work on different geographical location, this may become an added challenge.

• A trend to ignore documentation

The Agile Manifesto stresses more on delivering working software over comprehensive documentation. It is beneficial, as it reduces the unnecessary work. However, depending on the project, the team will have to strike a proper balance between the code and the documentation.

Q-5. What are the critical differences between Agile and other traditional (Waterfall or Spiral) models?


Following are the critical differences between Agile and other traditional models.

– Approach

The agile methodology uses an iterative and team-based approach. Its objective is the quick delivery of the software. However, the conventional model uses a linear method, where different stages of software development process execute one by one. Thus, one step has to complete before the next one begins.

– Product Requirements

In the Agile model, the requirements can change at any point of time as per the customer expectations. Sometimes they are vague and not very clear. However, in traditional models, the requirements are made very clear before the team enters into the development phase. Any change in the scope during the development phase is not readily accepted.

– Project Size

Agile process divides a project into short Sprints, hence a small team is required. However, in traditional models, the size of the project is usually big; therefore, needs a big group.

– Project Architecture

In the Agile model, the architecture includes only those requirements that add value to the product and are required. However, In traditional models, the architecture is built keeping in mind the current as well as the future requirements.

– Project Planning and Control

In the Agile model, the planning of the project is Internalized and has qualitative control.

However, in traditional models, the plans are appropriately documented and have quantitative control.

– Customer Involvement

In the Agile model, there is close collaboration between the customer and the development team. The team invites them in every meeting organized before, during and after every ‘sprint.’ However, in the traditional model, the customer involvement is more till the time requirements get finalized. After that, they get involved on the need basis only.

– Refactoring

In the Agile model, refactoring is not costly. However, it is expensive in traditional models.

– Amount of Risk involved

Due to higher uncertainty, the chances of occurrence of unknown risks are more in the Agile model. It can impact the project significantly. However, in traditional models, the risks involved are well identified in advance. Hence the impact of the risk on the project is very less.

Q-6. How does Agile ensure quality?


Agile proposes the following practice to ensure the quality of the product-

  • Iteration
  • Re-factoring
  • Dynamic code analysis
  • Short feedback cycles
  • Reviews and inspection
  • Standards and guidelines
  • Milestone reviews

Q-7. How will you choose between Agile and Waterfall model for any project?


Both Waterfall and Agile models are time-proven project development methodologies that can help to manage the project in an organized way and build a high-quality product. In brief, you can make your choice between Agile and Waterfall model based on the following two words: flexibility vs. stability.

Agile has the edge over Waterfall model when

You’re working on a new product having requirements that are subject to change, and you want to achieve speed at work as well. Suppose complete information is not available at the beginning of the project for defining strict requirements and planning, it can lead to costly mistakes further down the line. Agile was introduced to reduce this cost of change and uncertainty. It is why Agile is a hot favorite of startups these days. Agile outshines when you don’t have a clear picture of the end goal and requirements are continually changing.

Waterfall has the edge over the Agile model when

The requirements are defined and freeze in coordination with the clients at the beginning of the project, and you’re very confident that there won’t be any significant changes in scope throughout the project. Thus, when the plan is predictable and straightforward, you can benefit from the Waterfall model’s inherent stability and linear development path.

Q-8. Explain the between burn-up and burn-down chart?


Burn-up and burn-down charts are maintained to track the progress of the project.

Burn-up charts represent the work that has been completed in any project whereas Burn-down chart represents the work remaining in that project.

Q-9. What is the Product Backlog?


The product backlog contains every feature and user requirements required to develop, maintain and sustain a product. It is the responsibility of the Product Owner to manage the Product Backlog.

In its early stage, the Product Backlog contains the initially identified requirements as per the understanding at that time. The Product Backlog grows as the product and the environment in which it will operate gets unfold. Thus, it is appropriate to say that the Product Backlog is dynamic. It continually updates to capture any change that is required to make the product more appropriate, competitive, and useful. Product Backlog will always be there for an existing product.

Q-. What is the Sprint Backlog?


The Sprint Backlog is a subset of Product Backlog. It lists those features and requirements, identified by the team that they will complete in that Sprint.

During the Sprint planning, the team selects a few items from the Product Backlog, called as user stories. Next, they identify the tasks needed to complete each of the user stories and also estimate the time, which will be taken by any team member to complete that task.

It is essential that the team members select the items and duration of the Sprint Backlog. Since they are the owners of the tasks, so they must choose what they are committing to deliver in the Sprint.

People commonly use a Spreadsheet to maintain the Sprint Backlog. However, you can also use any software created to manage Agile processes. An example of a sprint backlog in a spreadsheet looks like this:

During the Sprint, team members are required to update the Sprint Backlog at least once in a day. It may be about the progress in the task or any new information. Some teams do this in the daily Scrum.

Let’s now check out a few more Agile interview questions for development and testing.

Q-11. What is Scrum in Agile?


Scrum is one of the most commonly used frameworks for implementing the Agile methodology. Both Scrum and Agile terms appear together so often that people confuse them to be the same.

Even though there are so many frameworks available in the market to implement Agile like Kanban, XP to name a few, the Scrum has become so popular, as it provides a unique flavor by being a “lightweight process framework.”

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each of these components serves a definite purpose and is crucial to Scrum’s success.

Q-12. Why do we call Scrum as a lightweight process framework?


The “Lightweight” here means to keep the process overheads as small as possible so that the team gets the maximum time to do productive work.

The phrase “process framework” represents a set of practices. They are as follows:

The Scrum framework works by dividing the product development into fixed-length iterations called Sprints.

These sprints are of small duration, with frequent releases, giving the team and the customer confidence about the tangible progress of the product.

The feedback that the team gets from the stakeholders in the Sprint demo creates a powerful way to develop a competitive and useful product.

It imbibes a feeling of inspiration to work even better in the next Sprint.

The small size of the release strengthens the importance of accurate estimation and early feedback from validation.

Q-13. What are the primary artifacts of Scrum process framework?


Scrum Artifacts provide all the crucial information that the Scrum Team and the stakeholders must know to understand the product under development; the activities accomplished and those planned and yet to be done to complete the project.

Scrum Process Framework suggests maintaining the following artifacts-

  • Product Backlog
  • Sprint Backlog
  • Burn-Down Chart
  • Increment

These are the minimum set of tools required in a Scrum. However, the Scrum process does not restrict to have more artifacts if needed.

Q-14. Name the ceremonies conducted in each Scrum Sprint?


The Scrum ceremonies are time-boxed events. It means that every event prescribed by Scrum has a predefined maximum duration in the project. Each of these events enables the team to adapt and inspect. They also provide clarity to the stakeholders on the progress of the project.

Scrum calls for the following four ceremonies to ensure proper progress of the Sprint:

  • Sprint planning
  • Daily stand-up
  • Sprint demo
  • Sprint retrospective

Q-15. Describe the different events executed in a Scrum?


Sprint Planning

It is the event in which the Product Owner presents the prioritized product backlog to the development team with high business value tasks as the priority items.

All team members collaborate to understand the work.

After that each member picks up the items, he/she will finish in the Sprint. Product Owner or Scrum Master cannot force the team to pick up more tasks.

The team then defines the Sprint Goal based on the items taken up in the Sprint.


  • Attendees – Development Team, Product Owner, and Scrum Master.
  • Occurrence – At the inception of the sprint
  • Time-box – Max. eight hours for a four-week sprint.
  • Input – Product backlog, the current product increment, the definition of done (for every user story), team capacity, average velocity.
  • Output – Sprint goal, Sprint backlog, a clear picture of the work to be done during the sprint.

Daily Scrum

It is a 15 minutes meetup where team members gather to sync up on a daily basis.

The scrum master organizes this event, decides the time and place which doesn’t change often.

Every team member keeps the agenda limited to following points.

  • What did I do yesterday?
  • What will I do today?
  • Are there any issues or Impediments?

The purpose of Scrum is to monitor the progress of Sprint goals in the daily standup. The regular 15-minute get to gather helps each member to collaborate and work in a self-organized manner.

It’s Scrum master’s role to ensure that every member attends the daily standup. It encourages better communication, timely decision, and sharing knowledge.

The daily Scrum inspires the team to learn inspection as well as adoption.


  • Attendees – Dev Team, Scrum Master (Product Owner – Optional)
  • Occurrence – Daily, same place, and at the same time
  • Time-box – 15 mins at most.
  • Input – Team asks three questions – “What did I do yesterday?”, “What will I do today?” and “Are there any issues or Impediments?”
  • Output – Reveal the current status of the Sprint goal, any issues or probable impediments if any.

Sprint Review

It is a significant activity that is carried out at the end of each Sprint. The principal objective of the Sprint review is to inspect the product created in the Sprint and modify the Product Backlog if needed.

The Development team demonstrates its work to the Stakeholders to get their feedback. During the review meeting, Scrum Team and the Stakeholders collaborate to discuss what tasks they have completed in the Sprint and what they will take up next.


  • Attendees – Development Team, Scrum Master, Product Owner, and Stakeholders.
  • Occurrence – At the end of the Sprint and before Sprint retrospective.
  • Time-box – Four hours if the Sprint’s duration is one month.
  • Input – Product Increment, updates for the Product Backlog identified in the Sprint.
  • Output – Updated Product Backlog, New Idea( if any), a better understanding of tasks and product.

Sprint Retrospective

This meeting enables the Scrum team to inspect itself and devise a plan for accommodating the improvements, identified for the next Sprint.

The prime objective of the Sprint retrospective is-

To review how did the current Sprint performed concerning processes, tools, and interaction with people.

Recognize the items that went well and potential improvements.

Devise an action plan to implement improvements that will further help the team to enhance product quality.

Scrum Master boosts the team to improve itself in the Scrum process framework, as well as the other processes they practice so that they can work more efficiently in the upcoming Sprint.

During each Sprint Retrospective, the Scrum Team tries to identify and list out ways to increase product quality by improving on the work processes or by adopting the definition of “Done,” only if its appropriate and not in conflict with the standards of the organization.

Towards the end of the Sprint Retrospective, it’s the responsibility of the Scrum Team to list the improvements that it will implement in the coming Sprint. The Scrum team displays adaptation to the inspection by implementing these reforms in the next Sprint.


  • Attendees – Development Team, Scrum Master, Product Owner
  • Occurrence – After Sprint Review has completed, Towards the end of the Sprint.
  • Time-box – Three hours if the Sprint’s duration is one month.
  • Input – Results from the Sprint, Sprint Events.
  • Output – Lesson learned in the current Sprint, Improvements and corresponding list of actions for the succeeding Sprint.

Q-16. Define the primary roles of the Scrum process framework?


The Scrum prescribes three roles, namely a ScrumMaster, a Product Owner, and the Development Team.

Product Owner

A Product Owner is a stakeholder of the project.

1- He has the responsibility of maintaining the Product Backlog.

2- He works with the end users and the customers to get a clear vision of the requirements.

3- He then provides the criteria to the team to build the proper product.

4- He ensures that the Team understands the conditions to the level needed.

A Product Owner is a single person, not a group of people.


The ScrumMaster coaches the Scrum team about the Scrum processes and finds out ways so that team can work on it smoothly.

1- He keeps a check on the development team to ensure that they are executing the committed tasks properly.

2- He works to resolve the impediments and distractions for the development team. Thereby helping the team to increase their efficiency and productivity to achieve the Sprint goal.

3- He facilitates the critical meetings like Sprint planning, Stand-up, Sprint Review, and the Sprint Retrospective by arranging for the required resources (both human and logistics).

Development Team

1- It is a group of individuals working together to deliver the requested and committed product increments.

2- Every member of the Development Team is self-organizing and cross-functional. Self-organizing means they work on their own to accomplish their task in a best possible way. No one from the team directs them, about how to perform their activities. Cross-functional means they have all the competencies required to complete the work without depending on others.

3- All members of the team work in close coordination to ensure timely and successful completion of the Sprint.

4- An optimally sized Development Team comprises of 5 to 7 members. They should be co-located to work efficiently.

Individual Development Team members may have specialization in certain areas. But, Scrum never associates a success or a failure to a single team member. Instead, the whole Development Team is accountable for the timely delivery of the committed release with the defined quality.

Q-17. What are the responsibilities of a Scrum Master?


Key responsibilities of a Scrum Master involves:

  • Organizing scrum events (Daily standup, Sprint planning, and review)
  • Facilitating technical discussion
  • Sprint goal tracking
  • Spread the agile process awareness
  • Ensure product quality
  • Address impediments
  • Protect the team from external pressure
  • Find ways to increase team velocity.
  • Report release progress

Q-18. Explain Velocity in Agile?


Velocity determines the amount of work a Team can handle during a Sprint.

The team calculates the velocity at the end of the Sprint by adding the Points of all the User Stories, completed in that iteration.

Q-19. What is User Story in Agile?


A User Story provides a simplified description of a software feature from an end-user perspective. Product Owner creates the User Stories keeping in mind the users’ viewpoint and captures the ‘who,’ ‘what’ and ‘why’ of a requirement.

First of all, a story requires a title that briefly summarizes about (what is) its purpose: For example, ‘Update the Birthdate.’ Now, PO has to add a description for which he can use the following template:

As a <role> I want <feature/ target >, <benefit/ reason>.

Example of User Story:

As a user, I want to upload my birthdate so that I can share my birthdate with my friends.

PO can add more information like acceptance criteria, specifications, and wireframes. Acceptance criteria are particularly important because it tells the developers about what must be done to complete a User Story and to validate that the User Story is working as intended.

Product Backlog in Scrum contains the complete list of User Stories. These User Stories are prioritized and brought into the Sprint Backlog in the Sprint Planning Meeting.

Developers do the effort estimation, based on the User Stories included in the Sprint and User Story Points provides an estimate of the size of the product.

Now is the time to check out some essential Agile interview questions for development and testing.

Q-20. What are the three pillars that make Scrum work?


Scrum works on the notion of experience-based and evidence-based process control theory called Empiricism.

The three pillars of Scrum that support the implementation of empirical process control are as follows:

  • Transparency
  • Inspection
  • Adaptation


There is transparency in presenting the facts. Be it good or bad; people involved have the strength and feeling of trust to keep each other informed about it.

All the people involved in the project collectively, collaborate and strive to achieve a common organizational objective.

All participants must share a common language regarding the process. Those who are working on the product and those reviewing it must share a standard definition of “Done.”


Scrum allows inspecting the processes, people aspects, practices, and even continuous improvements if needed for the product.

The team openly and transparently demos the product to the customer at the end of each Sprint, to get their valuable feedback.

If the customer changes the requirements during the inspection, the team does not complain but instead adapts to the customer expectations.


Here, adapting means accepting changes with ease for continuous improvement. Scrum renders the ability to adjust based on the results of the inspection.

Ability to adapt eventually lead us to fulfill the reasons for adopting the Agile methodology, for example, quicker time to market, increase in return on investment through value-based delivery, reduce in total cost of ownership through enhanced software quality, and improved customer and employee satisfaction.

Q-21. How long does a scrum cycle last? Who is involved in the Scrum cycle?


Scrum cycle depends on the nature of the project the team is working. It usually ranges from 2-4 weeks to the maximum size of about a month.

Scrum cycle requires the involvement of following people.

  • Scrum master
  • Product owner
  • Team

Q-22. What is the purpose of Refactoring?


Code Refactoring is the process of rethinking the design of a feature and implementing the code such that it improves the quality and maintainability of the source. Hence this exercise enhances the performance of the product.

Agile teams make frequent modifications in the code during the Sprints, and it is not easy to accomplish, without investing into Refactoring.

Refactoring is essential because un-refactored code tends to rot. This lousy code may take several forms.

  • Introduce unwanted dependencies between classes or packages.
  • Assign inadequate class responsibilities.
  • Too many responsibilities associated with a method or class.
  • Duplicacy in the code.
  • And numerous other types of complexities and clutter.

Q-23. What is Sprint Zero in Scrum? Why was it introduced?


Some organizations introduce a Sprint Zero before the project kicks off actually. This Sprint might be used to accomplish the following tasks.

  • For assembling the Scrum team.
  • Finding a resolution for hardware, software, and colocation issues.
  • If required, train a team in Scrum or other technology.
  • To populate the product backlog with a few high-level items as a preparation for the first Sprint planning meeting.

Q-24. What is the need of splitting User Stories into tasks?


A lot of Scrum teams follow the practice of splitting User Stories into tasks. Following are its benefits.

It can help in doing more accurate estimations. Tasks are small; this will help the developers to estimate the amount of work involved in a story more precisely. It minimizes the chances of missing any action point.

Multiple developers can work on the same story. Scrum focuses on completing the top priority story. So as a team we also want to “burn” the top priority story as fast as possible before working on the second top priority one, and so on. Independent tasks will allow multiple developers to work on the same story in parallel enabling the team to finish it as soon as possible.

Senior developers can guide the juniors and check that they are exercising a right approach towards a User Story.

It allows us to measure the progress. Individual team members keep on updating the progress on the tasks. When developers start to work, they change their status from “not started” to “in progress” and finally to “done.” Since these tasks collectively make a User Story, thus we get a clear picture of the progress of the User story as the number of tasks associated with it to move to “done” state.

Q-25. What are the impediments?


Any obstacle which hampers the smooth functioning of the team, due to which they are not able to perform their tasks in a better way and on time. We call it ‘impediments.’

Q-26. Explain the fundamental difference between Epic, User Story and Task?



A group of related User Stories is called an Epic.

User Story

A User Story represents the actual business requirement.

It is the Product Owner who creates User Stories from the requirements.


A User Story is broken down into small action items called Tasks. Team members work on these Tasks to accomplish the User Story. Merging the work done for associated Tasks implements the User Story.

Q-27. What is a Taskboard in Agile?


A Taskboard is a physical dashboard which displays the user stories included in the current Sprint Backlog, along with its constituent tasks. Usually, the team uses index cards or post-it notes to show the information on the Taskboard. The Taskboard get divided into following columns.


This column contains a list of all the User Stories in the current Sprint Backlog.

Not started

This column contains those Tasks of the User Stories on which work has not yet begun.

In progress

This column contains all the Tasks on which work has already begun.

To Verify

This column contains the Tasks pending for verification or testing.


This column contains all the tasks which are complete.

You can say that the Taskboard is a visual display of the progress of the Scrum team during a Sprint. As the Sprint progresses, the cards mentioning the individual tasks move from the leftmost column of the Taskboard towards the right. Once all the Tasks associated with a particular User Story gets completed, it gets switched to the ‘Done’ column.

Q-28. What are the different techniques to split a User Story?


Most of the User Stories are available during planning. Now the team has to break down these User Stories into Tasks to get them implemented.

Several techniques and tools are available nowadays that help to split these User stories effectively.

Here, I would like to introduce you to one such fast and straightforward ‘SPIDR’ method devised by Mike Cohn. He has compiled five techniques with which you can divide almost every large User Story.

1- Spikes

Spikes are small, prototypical implementations of any functionality that gets used for the evaluation and feasibility of new technologies.

This method involves investigations and building knowledge based on the acquired information. This research activity provides the knowledge one needs to split a complicated story.

However, this method should be used only if the rest of the SPIDR methods have not worked to the expectation. The team can make use of this new knowledge, and understand the User Stories more accurately, and hence it becomes easy to split them. This method, however, is more abstract and therefore difficult to practice than the remaining ones.

2- Paths

If a user story has many possible paths, then you can create separate artifacts for some of them. Avoid overuse of this technique, do it where it makes sense.

For example, if a user wants the payment feature for purchasing from an online store. There could be two possible paths such as either use a credit card or pay using Paypal.

You can further split the credit card payment feature based on their type. But make a judgment before creating a story for different kinds of credit card.

The primary task of paying for purchases is, however, segregated well into the two alternatives stories. And now you have new stories which are smaller and easy to estimate.

3- Interface

An interface could be a device or the device type, such as smartphones running on iOS or . We can split the user stories based on this diversity.

Let’s use the example of distinct OS and browsers: In a project, we might have user stories that work only for Android devices or others that use the web browsers.

To avoid making stories too broad and detailed, you need to consider which devices or interfaces you want to support. Perhaps the first iteration of the development can cover the Android devices, because of the greater user-base.


It is another technique for splitting user stories.

One can use it when the initial stories involve data from a range.

For example, a travel portal aims to target tourists for traveling to a specific city. If the city is famous for its museums, then the first story should include the list of different museums in that area. Subsequently, the next story might organize the tourist tours across the city and one more to manage the outdoor tasks.

5- Rules

You can also split based on the business rules or technical standards.

For example, in online booking of cinema tickets, there could be several constraints on the business requirements of the target cinema, such as one can only purchase a maximum of 10 tickets for a unique e-mail address.

With this story it would be conceivable that the development team omits this restriction, allowing every visitor to buy as many tickets as they wish. The constraint can get added in a second iteration step. Incremental delivery such as this means that initial stories don’t get fully implemented immediately, but instead are delivered in several smaller steps. Sometimes it makes sense to neglect technical specifications or business rules if by doing so you can more quickly achieve a satisfactory result that satisfies the user or client. You can retrieve the omitted stories at a later date.

Q-29. What is a good User Story?


Bill wake used an acronym INVEST in his book on “Extreme Programming” for defining the characteristics of a well-formed user story.

1- Independent

It means that each story has an atomic nature and hence is independent of the other stories.

2- Negotiable

The sprint and business team should be able to negotiate on the scope of a story based on the functional, financial or technical terms.

3- Valuable

A story should bring value to the stakeholders.

A user story which is functional has to create some business value.

There could be stories related to the technical debt; they should improve the architecture, usability or the scalability.

4- Estimable

A good story is the one which the team can estimate easily and provide the story points.

5- Small

The size of a story should be small enough to fit in a sprint.

6- Testable

The story should have a clear description of the work which the team can refer and implement.

Next are a few Agile interview questions for development and testing based on the sprint and user stories.

Q-30. What are different activities performed in a User Story?


  • Grooming – Architects and the team grooms a story to finalize its design.
  • Development – The team implements the design.
  • Unit testing – The team writes unit tests for the code changes made to develop the story.
  • Static code analysis – It checks for errors, memory issues, and security flaws in the code.
  • Dynamic code analysis – It reveals memory leaks at runtime.
  • Functional/Regression tests – The team prepares and executes the functional tests.
  • Automation – The team performs the automation for the newly added features. Each automated tests becomes the part of regression testing.
  • Code coverage (CC) – The team use CC tools to measure the lines of code covered by the automation.

Q-31. What is the Sprint Goal?


Sprint goal is to implement all the stories committed in the planning meeting. The team sets the goal during the Sprint planning and assesses it in the review meeting.

Sometimes the goal may also include the activity like quality improvement or refactoring.

Q-32. What is T-shirt sizing in Agile?


T-shirt sizing is a technique which aims to allow relative sizing. You can compare stories, split into multiple parts. The T-shirt has the following criteria.

  • Extra-small,
  • Small,
  • Medium,
  • Large, and
  • extra-large.

Q-33. What are the differences between Scrum and agile?


Both the terms, Agile and Scrum appear in the project management.

The Agile is a methodology which emphasizes the incremental and iterative model called as sprints.

Scrum, on the other hand, is a type of Agile framework used for software development.

Q-34. What is a Scrum call?


The Scrum call is the daily standup meeting which team holds regularly. It mostly occurs at the same location and at the same time each day.

Ideally, this meeting happens in the morning, as it sets the tone for the entire day’s work.

Q-35. What is a Sprint duration?


In Agile Scrum, the standard Sprint duration is one week in length. However, the two-week sprints are a common practice for the software product development. Many of the Scrum trainers and coaches guide the Sprints to be one or two weeks in size.

Q-36. Can a Sprint be allowed to extend?


It’s not a good practice to extend the Sprint. It is so because the velocity could vary in different sprints. Also, the Sprint length is not a joke.

Another framework is Kanban which doesn’t have iterations or Sprints. You can follow Scrum and borrow elements of Kanban and XP as you find suitable. But you should practice having a fixed Sprint length.

Q-37. What is the ideal duration of a sprint planning meeting?


A sprint in Agile starts with the sprint planning. If its length is one month or four-week, then this meeting can go up to eight hours.

For a two-week cycle, do planning for around four hours. The general thumb rule is to multiply the no. of weeks in the sprint by two hours and calculate the size of total sprint planning meeting.

Q-38. Who has the right to cancel the sprint?


It’s the PO (product owner) who has the right to abort a sprint. He should do so only before the Sprint duration is over.

A Sprint can also get canceled if the Sprint Goal becomes antiquated.

Q-39. What is the duration of the sprint review meeting?


The duration of the sprint review meeting changes depending on the sprint duration.

For a one-week sprint, the meeting can take about one hour; for two weeks sprint, the limit is two hours.

The teams using the four-week model for sprints should allow at least four hours for this meeting.

Q-40. What is a sprint retrospective?


The sprint retrospective is one of the Scrum activities where the team discuss the pain points faced in the last sprint and picks a few to overcome in the next cycle.

It mostly occurs at the end of a sprint and after the review meeting. The product owner, scrum master and all the team members should attend this Scrum event.

Q-41. What does a scrum master do in the Agile scrum?


The Scrum Master is also one of the members of the team. His role is to assist the team in becoming self-organized, self-managed and to see the team achieves the goal of the Sprint.

Q-42. Why is the sprint review required?


The Agile team should do the sprint review because here, they can assess the project progress against the sprint goal completed during the sprint.

Q-43. Who is responsible for the quality in Scrum team?


In the Agile Scrum, the entire team is responsible for the overall quality of the product in development.

However, the book says that the Product Owner (PO) is ultimately own the quality and optimizations.

Q-44. What is the primary objective of the Sprint Burndown chart?


A sprint burndown chart displays the outstanding work on the vertical axis whereas the time on the horizontal.

1- It is a running chart to highlight the work which is remaining.

2- It helps in forecasting when the work will get finished.

3- It is a common practice to use it in the agile software development methods such as Scrum.

Q-45. What is the Sprint Velocity?


Velocity represents the volume of work a Scrum team can finish in a single Sprint. Hence, it is one of the vital metrics in Scrum.

Velocity gets determined towards the end of the Sprint by summing the points for all the finished User Stories.

Q-46. How many user stories should you have in a sprint?


Many coaches suggest adding three to six user stories per sprint. But it’s not the correct rule of thumb. For a team of seven members, if you add over 20-40 user stories, then they are too many to complete.

So, five to fifteen is the right count. You can set four as the lower limit, and twenty is an upper cap.

Q-47. What is the story point estimation?


In Agile Scrum, we use story points (SP) as a unit for measuring the work. Each story has given a specific estimate in the form of SP.

Q-48. What does a story point represent?


A Story Point (SP) is a subjective metric of estimation used in the Agile Scrum model. A Story point represents the volume of work or efforts needed to complete a user story.

Q-49. What are the different estimation methods in agile?


1- Planning Poker
2- T-Shirt Sizing
3- Dot Voting
4- The Bucket System
5- Affinity Mapping
6- Ordering method

Q-50. What is the Sprint capacity?


The capacity in Agile is a vital measure to inform the team how much work it should commit during the sprint planning. It is a rough but quick way for determining the capacity of the Agile team for a single sprint cycle.

Summary – Agile Interview Questions for Dev and Testing

Hope, the above agile interview questions and answers would help you in skill and career building. If you wish to learn this process from depth, then do read our post on the agile methodology.

If you like us to cover more topics on Agile, then do write to us.



Source link


Please enter your comment!
Please enter your name here