Are you looking to brush up your knowledge of Agile methodology? Or perhaps you’re preparing for an upcoming Agile interview? Well, you’re in luck because we’ve got you covered with the top Agile interview questions in this post!
Our aim is to help you understand Agile as a software development methodology, how it works, its principles, who is involved, and the best practices, tools, and techniques to make the most out of this method.
If you’re a software engineer, whether you work as a developer or a tester, it’s essential to read these Agile interview questions. Agile is a process that fosters collaboration, supports interchangeable roles to increase productivity, and enforces trust among the team.
So, get ready to dive into the most important Agile interview questions for both development and testing. By the end of this post, you’ll be well-prepared to ace your Agile interview and have a better understanding of Agile methodology.
Crack Your Agile Interview: 50 Must-Know Questions!
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?
Answer.
Agile is a continuous software development methodology that is quite popular these days. It focuses on building the ability to the changing needs quickly and at the same time implementing it with ease.
The agile method splits the product development work into small increments called ‘Sprints’ or Iterations. Each of these Sprints is of short time duration, which typically lasts from one to four weeks.
Each iteration involves planning, coding, and testing. Toward 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?
Answer.
The 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 the actual delivery of the product. The Agile Manifesto constitutes four foundational values and 12 supporting principles that drive the Agile approach to software development.
Agile methodology preaches the following 12 principles –
Agile Principles
- Customer Satisfaction via prompt delivery of working software.
- Adapt to the changing requirements for the benefit of the customer.
- Deliver frequent releases of working software to the customer. Plan every deliverable in the shortest possible time, maybe weeks.
- There should be close coordination between the developers and the business people for the entire duration of the project.
- Projects need motivated people. Trust them by providing the support they need.
- Face-to-face discussion is the best mode of communication with the team.
- Working software reflects the current state of the project.
- Agile processes promote sustainable development. Developers should be capable of maintaining a uniform pace.
- Consistent efforts are to be made to achieve technical excellence and robust design.
- Add simplicity by filtering out the things that do not add value. Focus on the most needed features to avoid unnecessary work.
- Self-organized teams usually create the best designs.
- 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 drives the development process.
– Working software over Comprehensive documentation:
Agile prefers working software over comprehensive documentation. It works on the notion that the customer would like to see a feature running rather 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, focuses on quick response to change and continuous development.
Q-3. What are the advantages of using Agile Methodology?
Answer.
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 at 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 daily interactions between the business people and the developers.
- Agile allows accommodating changes in the requirements even at the later stages of 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?
Answer.
Like other development approaches, Agile may have drawbacks for some products and teams.
• Anticipates a 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 the addition of some new requirement towards the end of the Sprint. Despite, a high level of planning, it is always possible that some deliverables may not get completed on time due to some unidentified issues. It’s the bare truth of all projects. The 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 development teams that work in different geographical locations, 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 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?
Answer.
Following are the critical differences between Agile and other traditional models.
– Approach
The agile methodology uses an iterative and team-based approach. Its primary objective is the quick delivery of the software. However, the conventional model uses a linear method, where different stages of the software development process are executed one by one. Thus, one step has to be completed before the next one begins.
– Product Requirements
In the Agile model, the requirements can change at any point in time as per the customer’s 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
The 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 to 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 a 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 higher 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 much less.
Q-6. How does Agile ensure quality?
Answer.
Agile proposes the following practices to ensure the quality of the product-
- Iteration
- Refactoring
- Dynamic code analysis
- Short feedback cycles
- Reviews and inspection
- Standards and guidelines
- Milestone reviews
Q-7. How will you choose between the Agile and Waterfall models for any project?
Answer.
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 the Agile and Waterfall models based on the following two words: flexibility vs. stability.
Agile has the edge over the 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. This 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 frozen 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 difference between burn-up and burn-down charts.
Answer.
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?
Answer.
The product backlog contains every feature and user requirement 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-10. What is the Sprint Backlog?
Answer.
The Sprint Backlog is a subset of the 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 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, they must choose what they are committing to deliver in 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 a day. It may be about the progress of 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?
Answer.
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, and XP to name a few, 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 a lightweight process framework?
Answer.
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 the Scrum process framework?
Answer.
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 having more artifacts if needed.
Q-14. Name the ceremonies conducted in each Scrum Sprint.
Answer.
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.
Answer.
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, and he/she will finish in the Sprint. The 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.
Summary
- 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, and 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-minute meetup where team members gather to sync up on a daily basis.
The scrum master organizes this event and decides the time and place which doesn’t change often.
Every team member keeps the agenda limited to the 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 the Scrum master’s role to ensure that every member attends the daily standup. It encourages better communication, timely decisions, and sharing of knowledge.
The daily Scrum inspires the team to learn inspection as well as adoption.
Summary
- Attendees – Dev Team, Scrum Master (Product Owner – Optional)
- Occurrence – Daily, same place, and at the same time
- Time-box – 15 mins at most.
- Input – The 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, and 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, the Scrum Team and the Stakeholders collaborate to discuss what tasks they have completed in the Sprint and what they will take up next.
Summary
- Attendees – Development Team, Scrum Master, Product Owner, and Stakeholders.
- Occurrence – At the end of the Sprint and before the 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 Ideas ( 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 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 it’s 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.
Summary
- Attendees – Development Team, Scrum Master, Product Owner
- Occurrence – After Sprint Review has been 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.
Answer.
The Scrum prescribes three roles, namely a ScrumMaster, a Product Owner, and the Development Team.
Product Owner
A Product Owner is a stakeholder in 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.
ScrumMaster
The ScrumMaster coaches the Scrum team about the Scrum processes and finds out ways so that the 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 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 the 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 comprised 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 with 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?
Answer.
Key responsibilities of a Scrum Master involve:
- 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.
Answer.
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 a User Story in Agile?
Answer.
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 (what is) its purpose: For example, ‘Update the Birthdate.’ Now, the 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 they tell 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 provide 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?
Answer.
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
Transparency:
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.”
Inspection:
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’s expectations.
Adaptation:
Here, adapting means accepting changes with ease for continuous improvement. Scrum renders the ability to adjust based on the results of the inspection.
The ability to adapt eventually leads 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, reduction in the 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?
Answer.
The scrum cycle depends on the nature of the project the team is working on. It usually ranges from 2-4 weeks to the maximum size of about a month.
The scrum cycle requires the involvement of the following people.
- Scrum master
- Product owner
- Team
Q-22. What is the purpose of Refactoring?
Answer.
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 in 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 are 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?
Answer.
Some organizations introduce a Sprint Zero before the project kicks off. 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 in preparation for the first Sprint planning meeting.
Q-24. What is the need for splitting User Stories into tasks?
Answer.
A lot of Scrum teams follow the practice of splitting User Stories into tasks. The 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 the right approach toward a User Story.
It allows us to measure progress. Individual team members keep on updating the progress of 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, we get a clear picture of the progress of the User story as the number of tasks associated with its move to the “done” state.
Q-25. What are the impediments?
Answer.
Any obstacle that 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.
Answer.
Epic
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.
Task
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?
Answer.
A Taskboard is a physical dashboard that 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 is divided into the following columns.
Stories
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 verification or testing.
Done
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 are completed, it gets switched to the ‘Done’ column.
Q-28. What are the different techniques to split a User Story?
Answer.
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 using a credit card or paying 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 cards.
The primary task of paying for purchases is, however, segregated well into the two alternative stories. And now you have new stories that 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 Android. 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 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 Android devices, because of the greater user base.
4- Data
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 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 be 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?
Answer.
Bill Wake used the acronym INVEST in his book “Extreme Programming” to define 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 the scope of a story based on functional, financial, or technical terms.
3- Valuable
A story should bring value to the stakeholders.
A user story that is functional has to create some business value.
There could be stories related to technical debt; they should improve the architecture, usability, or scalability.
4- Estimable
A good story is one that 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 that the team can refer to and implement.
Next are a few Agile interview questions for development and testing based on the sprint and user stories.
Q-30. What are the different activities performed in a User Story?
Answer.
- Grooming – Architects and the team groom 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 test becomes part of regression testing.
- Code coverage (CC) – The team uses CC tools to measure the lines of code covered by automation.
Q-31. What is the Sprint Goal?
Answer.
Sprint’s 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?
Answer.
T-shirt sizing is a technique that 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?
Answer.
Both the terms, Agile and Scrum appear in the project management.
Agile is a methodology that emphasizes the incremental and iterative model called sprints.
Scrum, on the other hand, is a type of Agile framework used for software development.
Q-34. What is a Scrum call?
Answer.
The Scrum call is the daily standup meeting that 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?
Answer.
In Agile Scrum, the standard Sprint duration is one week in length. However, the two-week sprints are a common practice for 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?
Answer.
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?
Answer.
A sprint in Agile starts with sprint planning. If its length is one month or four weeks, 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 number of weeks in the sprint by two hours and calculate the size of the total sprint planning meeting.
Q-38. Who has the right to cancel the sprint?
Answer.
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?
Answer.
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 a two-week 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?
Answer.
The sprint retrospective is one of the Scrum activities where the team discusses 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?
Answer.
The Scrum Master is also one of the members of the team. His role is to assist the team in becoming self-organized, and self-managed and to see the team achieve the goal of the Sprint.
Q-42. Why is the sprint review required?
Answer.
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 of the Scrum team?
Answer.
In 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) ultimately owns the quality and optimizations.
Q-44. What is the primary objective of the Sprint Burndown chart?
Answer.
A sprint burndown chart displays the outstanding work on the vertical axis whereas the time is on the horizontal.
1- It is a running chart to highlight the work that is remaining.
2- It helps in forecasting when the work will be finished.
3- It is a common practice to use it in agile software development methods such as Scrum.
Q-45. What is the Sprint Velocity?
Answer.
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?
Answer.
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 as the upper cap.
Q-47. What is the story point estimation?
Answer.
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?
Answer.
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?
Answer.
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?
Answer.
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 to determine 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 will help you in skill and career building. If you wish to learn more, then do check out the following popular resources on our website:
- Agile Methodology in a Nutshell
- User Story Template | Agile Scrum
- More Agile Scrum Questions for Interviews
- Product Owner vs. Scrum Master
- Grooming in Agile Scrum
If you like us to cover more topics on Agile, then do write to us.
Best,
TechBeamers
