Top 40 Agile Scrum Popular Interview Questions

Agile Scrum Interview Questions

Agile Scrum is the best methodology to meet today’s demand for accurate projects. Agile is used in almost the majority of the organizations by now. Each member of the agile and scrum team is responsible to play an important role in the organization. For this, the interviewer seeks candidates with some good knowledge of Agile and Scrum concepts. So, it becomes essential to prepare yourself for some common and frequently asked Agile Scrum interview questions.

Agile & Scrum has been used in the market as synonyms. Majority of the time when agile is referred, it is meant scrum. Agile has transitioned from an optional knowledge to mandatory knowledge in today’s IT market and that’s the reason it is very important to know agile and for that matter Scrum. In this article, we shall try to understand why it has become mandatory to know Scrum in today’s IT market.

Here is a link to the Udemy course for more learning.

We have gathered a list of the most asked Agile Scrum interview questions. These are very common and basic questions which are expected from an interviewee who has worked in an Agile Environment.

1. What is Agile Methodology?

Agile is an iterative and collaborative process. The requirements and the solutions evolve through collaboration and in iterations. The collaboration and iteration must happen between the end-user and the team/person who is creating the product.

2. When should we use Agile?

Whenever there is an uncertainty in requirements/Changing Requirements, one should prefer Agile.

3. Which Industries uses Agile?

Predominantly used in software development. Many other industries including Automobile, Construction, Marketing and Advertising, Event Planning, Product Development, and Finance companies started using Agile

4. What is the basic difference between Agile and Waterfall models?

Agile Methodology

Waterfall Methodology

Agile model is considered unstructured compared to the waterfall model.

The agile process is broken into individual models that designers work on

The design process is not broken into individual models

The development process is iterative, and the project is executed in short (2-4) weeks iterations. Planning is very less.

The development process is phased, and the phase is much bigger than iteration. Every phase ends with a detailed description of the next phase.

The customer has early and frequent opportunities to look at the product and make the decision and changes to the project

The customer can only see the product at the end of the project

It requires close communication with developers and together analyzes requirements and planning

The developer does not involve in the requirement and planning process. Usually, time delays between tests and coding

Documentation attends less priority than software development

Documentation is a top priority and can even use for training staff and upgrade the software with another team

Every iteration has its testing phase. It allows implementing regression testing every time new functions or logic are released.

Only after the development phase, the testing phase is executed because separate parts are not fully functional.

Small projects can be implemented very quickly. For large projects, it is difficult to estimate the development time.

All sorts of the project can be estimated and completed.

At the end of every sprint, user acceptance is performed

User acceptance is performed at the end of the project.

An error can be fixed in the middle of the project. Testers and developers work together.

Only at the end, the whole product is tested. If the requirement error is found or any changes have to be made, the project has to start from the beginning. Testers work separately from developers

In agile testing when an iteration ends, all shippable features of the product is delivered to the customer. New features are usable right after the shipment. It is useful when you have good contact with customers.

All features once developed are delivered at once after the long implementation phase.

5. What are Agile software development principles?

Customer satisfaction by early and continuous delivery of valuable software.
Welcome changing requirements, even in late development.
Deliver working software frequently (weeks rather than months).
Close, daily cooperation between business people and developers.
Projects are built around motivated individuals, who should be trusted.
A face-to-face conversation is the best form of communication (co-location).
Working software is the primary measure of progress.
Sustainable development, able to maintain a constant pace.
Continuous attention to technical excellence and good design.
Simplicity—the art of maximizing the amount of work not done—is essential.
Best architectures, requirements, and designs emerge from self-organizing teams.
Regularly, the team reflects on how to become more effective and adjusts accordingly.

6. What are the different methods to implement Agile?

Kanban
Scrum
Lean
Dynamic System Development
Methodology (DSDM) Extreme Programming (XP)
Feature Driven Development
Rapid Application Development (RAD)

7. What is Agile Scrum?

Scrum is the most popular and simple Agile Framework. It is an agile development method which concentrates specifically on how to manage tasks within a team-based development environment. Scrum uses a time-boxed, iterative and incremental approach. Scrum is about developing complex products in the shortest sustainable lead time with maximum value.

8. Explain the entire Scrum Process.

There are 3 roles – Product Owner, Scrum Master, and Development Team (highlighted in Green in the Diagram)
4 ceremonies – Sprint Planning, Daily Standup, Sprint Review and Sprint Retrospective (highlighted in blue in the diagram), In addition to these 4 ceremonies there is an activity, which is known as Backlog Refinement Activity that is continuously in progress throughout the Scrum to refine the product backlog.
3 Artifacts – Product Backlog, Sprint Backlog and Product Increment (in Orange in the diagram).

Here is how the process works together –
1. Product Owner creates a Product Backlog which is the prioritized list of user stories.
2. Through Sprint Planning, the Development Team takes the items from the Product Backlog and creates the Sprint Backlog. This is done considering the capacity of the Sprint.
3. Sprint Backlog is the subset of Product Backlog.

4. The development team is the owner of the Sprint Backlog and they are responsible to complete the work by the end of the Sprint.
5. Sprint is a time-boxed iteration that usually lasts from 1 to 4 weeks in which the development team works on the Sprint Backlog.

6. In every 24-hours the team has the Daily Standup meeting coordinated by the Scrum Master in which mainly 3 points are discussed – what was done since the last meeting, what is the plan till the next meeting and if anyone has any impediments to complete the work. If there are any impediments then additional time is taken after the daily standups to plan to remove the impediment.

7. The work completed in the sprint becomes a Product Increment which can be potentially Shippable (deployable). The decision to deploy the product will be taken by the product owner.
8. At the end of the sprint, we have the Sprint Review Meeting where the Product Owner inspects the items concerning the Acceptance Criteria and Definition of Done and accepts or rejects based on the findings.

9. After the Sprint Review, the Sprint Retrospective meeting takes place. The team discuss what went well, what didn’t go well and what to improve to make the things better.
10. The team adopts the items to improve further and the process goes to the next sprint planning session.
11. This process continues on and on until all the items from the product backlog are not completed.

9. What is the role of the Product Owner?

Uses the Development Team to build valuable products for the Business
Drive Product Success
Primary Interface between the Scrum Team and the Stakeholders, Customer /Business Owner
Maintain & Prioritize Product Backlog
Create a Product Vision
Participate in Sprint Meetings

10. What is the role of the Scrum Master?

Produce a Development Team that can develop high-quality products at a sustainable pace
Implement the Scrum Framework and act as a Scrum Coach
Servant Leader
Remove Impediments
Protect the Team

11. What are the authorities of the Scrum Master?

Is not a Project Manager or doesn’t have any managerial authority
Don’t assign tasks to Team Members
Is not responsible for making sure everyone is busy
Don’t evaluate Team’s work for completeness or desirability
Can’t serve as a Product Owner

12. What is the role of the development team?

Development Team builds high-quality products at a sustainable pace
Consists of 4 to 9 members (Scrum Master and/or the Product Owner may be members)
Self-Organization
Cross-Functional
Collocation
Manage the Sprint Backlog and Track Sprint Progress
Attend in All Scrum Meetings

13. What are the authorities of the Development Team?

Authority to do whatever is needed to achieve the Sprint Goal.
Don’t overlap with the Product Owner Authority – can’t change the Acceptance Criteria of Sprint Backlog without the consent of the Product Owner.
Can’t ignore the externally-imposed constraints.
Can’t remove the Sprint Backlog item.

14. List Different Scrum ceremonies?

Sprint Planning Meeting
Daily Standup Meeting
Sprint Review Meeting
Sprint Retrospective Meeting
Backlog Refinement (Grooming) Activity

15. What is the Purpose of the Daily Standup Meeting?

To ensure that Development Team members are all on the same page
To ensure that they are making the best possible progress towards the Sprint Goal and Sprint Backlog
Re-plan the Sprint to achieve the Sprint Goal

16. Who is involved in the Daily Standup Meeting and when it is conducted?

The Development Team, the Scrum Master, and the Product Owner participate and the Scrum Master facilitates
Attendees typically participate while standing

Frequency – Every 24 Hours
Duration – 15 minutes or less (members may meet afterward for a more detailed discussion)

17. What happens in the Daily Standup meeting?

Every team member briefly answers the below questions during the meeting:

What did I do yesterday that helped the development team meet the sprint goal?
What will I do today to help the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting the sprint goal?

If any impediments are identified then additional discussion may happen afterward.

18. What is the purpose of the Sprint Planning Meeting?

Purpose of the Sprint Planning Meeting is to select the user stories for the next Sprint (Sprint Backlog Creation).

19. Who participates in Sprint Planning Meeting and when it is conducted?

The Development Team, Scrum Master, and Product Owner participate and the Scrum Master facilitates.

It is held before the Sprint starts and typically lasts 2 hours per week of a sprint (i.e., 4 hours for a 2-week sprint).

20. What happens in the Sprint Planning Meeting?

Product Backlog Review – Product Owner presents an ordered list of backlog items (based on the priority).
Sprint Backlog Creation – The Development Team selects the backlog item that they believe could be completed in the sprint (Sprint Backlog).
Task Identification – The Development Team identifies the detailed tasks of these backlog items.
After Task Identification the Development Team reassesses the Sprint Backlog:
- The user stories may be split further or
- The user stories may be put back into the Product Backlog if there is not enough bandwidth.

21. What is the purpose of the Sprint Review Meeting, who participates in it and when it is conducted?

The purpose is to allow stakeholders to review the work (Product Increment) that was completed during the sprint.
The Development Team, Scrum Master, and Product Owner and the other Stakeholders participate and it is facilitated by the Scrum Master.
It is held at the end of the Sprint. Duration – 1 hour per week of the sprint (2 hours for a 2-week sprint).

22. What happens at the Sprint Review Meeting?

The Team reviews the work that was completed and provides the necessary demos to the Stakeholders.
Review the planned work that was not completed (if any)
The team will discuss with stakeholders what work to be done in the next Sprint

23. What is the purpose of the Sprint Retrospective Meeting? Who participates and when it is conducted?

The purpose of the Sprint Retrospective Meeting is to discuss and improve the teamwork and/or the Processes.

The Development Team, Scrum Master, and Product Owner participate in this meeting while it is facilitated by the Scrum Master.
This meeting is conducted after the Sprint Review meeting and before the next Sprint Planning. Typically it lasts 45 minutes per week of the sprint (i.e., 1.5 hours for a 2-week sprint).

24. What happens in the Sprint Retrospective Meeting?

The entire team discuss below 3 main questions –

What went well?
What did not go well during the sprint?
What could be improved for better productivity in the next sprint?

The team self-identifies elements of the process that did or did not work during the sprint, along with potential solutions.

The purpose of Backlog Refinement (Grooming) Activity is to review the backlog items to make sure that they are appropriately prioritized and prepared in a way that is clear and executables for the teams.

The Development Team, Scrum Master, and Product Owner participates in this activity and it is facilitated by the Scrum Master

This is an ongoing activity throughout the Sprint. This should take 10% of the team’s time (~4 hours a week) and can be done in 2 hours twice in the week or an hour a day in the week.

26. What are the different Scrum Artifacts?

Product Backlog
SprintBacklog
Product Increment

27. What is the Product Backlog?

Product Backlog is a set of requirements placed in the order of importance as determined by the Product Owner.
The Product Owner creates the Product Backlog based on the inputs of the Customer & the Stakeholder.
Product Owner is accountable, however, the whole Scrum Team may contribute to the maintenance and refinement of the Product Backlog.
Product Backlog evolves constantly in Product Backlog refinement sessions.

28. What is the Sprint Backlog?

The sprint backlog is a subset of the Product Backlog that the team pulls into the Sprint to work on during Sprint Planning.
The tasks identified during Sprint Planning become part of the Product Backlog
This is a highly-visible, real-time picture of work, just enough detail to assist to Self-Organize the Development Team.
Development Team is the owner of the Sprint Backlog.
The scope of the Sprint Backlog can’t be changed by the Development Team that requires Product Owner Consent.
The Tasks in the Sprint Backlog can be changed by the Development Team as it evolves during the Sprint (New Task is added, Unnecessary Task is deleted).

29. What is the Product Increment?

Sum of the Product Backlog items completed during a Sprint.
Product Owner reviews the completed user stories in the Sprint Review meeting concerning the “Acceptance Criteria” and the “Definition of Done”.
Once the Product Owner accepts those user stories, those become the Product Increment.
This provides the list of ”Potentially Shippable” or ”Potentially Releasable” items after each Sprint.
Product owners will take a call if those completed items will be deployed to production.

30. What is the Definition Of Done (DoD)?

Done means every task under the User Story has been completed and any work created is attached to the User Story so the Product Owner can review it and make sure it meets his or her expectations.

To ensure that the Development Team agrees about the quality of work.
Become a checklist to check User Stories for completeness.
Scrum Team Creates Definition of Done.
This contains below items:
- Peer Review needs to be completed.
- Tests & QA have to be done.
- Should be Accepted By the Product Owner
This can be Project or Sprint level & not specific to a user story but apply to all user stories.

31. What are User Stories? How are they useful?

User Story is a tool used in Agile software development to capture a description of a small piece of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. The User Story usually takes 1-3 days to complete.
User Stories help to break down specific features into small manageable pieces.

32. What is the User Stories– Acceptance Criteria?

Acceptance Criteria defines what must be done to complete a user story. It specifies the boundaries of the story and is used to confirm if the functionality is working as intended and how to test it.
Product Owner Creates Acceptance Criteria.

33. What are the different Scrum Performance Metrics?

Sprint Velocity
Burndown Chart
- Sprint Burndown Chat
- Release Burndown Chart
Burnup chart
- Sprint Burnup Chart
- Release Burnup Chart

34. What is Scrum Sprint Velocity?

Velocity is the measure of the average amount of the work that the Scrum team can complete during a Sprint.
Different scrum teams may have different velocities even though everything else is the same (like team size, skillsets).

Velocity shouldn’t be used to compare one scrum team with another scrum team. It is tracked by the Development Team for use within the Scrum Team.

35. What is the Scrum Burndown Chart?

Burndown Chart is the graphical representation of the work left to do in a Sprint versus time.
There are 2 Burndown Charts:

Sprint Burndown Chart:
- It measures the work left vs time left in the Sprint.
- Team updates the Sprint Burndown chart daily.
- Helps the team to self-organize around the remaining Sprint work daily
Release Burndown Chart:
- It measures the work left in the release concerning the time left.
- Scrum Master updates the Release Burndown after every Sprint.
- It is mainly used by the Product Owner to manage the plan for the current Product Release.

Ideal Work Remaining – This is a straight line that shows ideally how the team proceeds to complete the workday over the day to meet the Sprint Goal at the end to complete all the work.

Actual Work Remaining – This is the actual work remaining. When Sprint starts it is the same as the ideal work remaining. As the Sprint progresses every day based on the actual completed work, the remaining work is determined and plotted in this graph.

If the Actual Work Line is above the Ideal Work Line, that means the Sprint is behind Schedule and if the Actual Work Line is below the Ideal Work Line that means the Sprint is ahead of Schedule.

36. What is the Scrum Burnup Chart?

Burnup chart is the graphical representation of the work completed versus time.
There are 2 Burnup Charts:

Sprint Burnup Chart:
- It measures the work completed vs time in a Sprint.
- Development Team updates the Sprint Burnup chart daily.
- It is a tool to understand the Sprint Progress
Release Burnup Chart:
- To measure the work completed in the release concerning the time.
- This is updated at the end of every sprint.
- It is a tool to understand Release Progress. It helps to see how much work has been completed, how much work has been added or removed and how much work is left to be done.

Total Work – Represents the total work to be done in the Sprint. In the graph, it is shown that some work has been added in between and at the end, some work has been deleted to complete the sprint on time.

Work Completed – This shows the actual work completed.
At any point in time, the Team can use this graph to project where they approximately will be at the end of the Sprint and accordingly adjust the work.