Top 100+ Scrum Master Interview Questions and Answers in 2021

StarAgile has gathered Scrum Master interview questions  to give certified professionals an idea on type of questions which may be asked during interview. After Scrum Master Certification most of the professional will update their profiles and plan to attend Scrum master interviews these questions will be useful specially for these professionals.

Scrum Master Interview Questions 

These interview questions for scrum master are prepared by industry experts from StarAgile who trains on CSM certification.

1. How does agile testing (development) methodology differ from another testing (development) methodologies?

The testers (developers) ensure that the whole process of testing (development) is broken into small steps as possible, and just a small unit of code is tested (developed) in each of these steps. The team of testers (developers) consistently communicates the results of their work and changes the short-term strategy and even the development plan on the go, based on the results of agile testing. Agile methodology encourages flexible and rapid response to change, which should lead to better end results.

2. How is scrum different from waterfall?

The major differences are:

• The feedback from the customer is received at an early stage in Scrum than waterfall, where the feedback from the customer is received towards the end of development cycle.
• To accommodate the new or changed requirement in the scrum is easier than waterfall.
• Scrum focuses on collaborative development than waterfall where the entire development cycle is divided into phases.
• At any point in time, we can roll back the changes in scrum than in waterfall.
• A test is considered as a phase in a waterfall, unlike scrum.

3. How is scrum different from the Iterative model?

Scrum is a type of iterative model only but it is iterative + incremental.

4. Do you know any other agile methodology apart from Scrum?

Other Agile methodologies include – Kanban, XP, Lean

5. What are the ceremonies you perform in a scrum?

There are 3 major ceremonies performed in Scrum:

Planning Meeting – Where the entire scrum teams along with the scrum master and product owner meet and discuss each item from the product backlog that they can work on the sprint. When the story is estimated and is well understood by the team, the story then moves into the Sprint Backlog.

Review Meeting – Where the scrum team demonstrates their work done to the stakeholders

Sprint Retrospective meeting – Where the scrum teams along with the scrum master and product owner meet and retrospect the last sprint they worked on. They majorly discuss 3 things:

What went well?

What could be done better?

Action Items

Apart from these three ceremonies, we have one more called “Backlog grooming” meeting. In this meeting, the scrum team along with the scrum master and product owner. The product owner put forward the business requirements as per the priority and the team discussed over it, identifies the complexity, dependencies, and efforts. The team may also do the story pointing at this stage.

6. Do you know the Three Amigos in Scrum?

The three Amigos are –

• Product Owner
• Scrum Master
• Scrum Team.

7. What do you think should be the ideal size of a Scrum team?

The ideal size is 7 to9 with +/- 2

8. What do daily stand up meetings entail?

Each day, at the same time and same place (in front of the task board), the team meets to give updates about their tasks and tickets resolved for the day. This meeting addresses SCRUM’s three questions listed below.

– What have you completed since the last meeting?

– What do you plan to complete by the next meeting?

– What is getting in your way?

9. What is the “time Boxing” of a scrum process called?

It’s called “Sprint”

10. What is a Release candidate?

A Release candidate is a build or version of the software that can be released to production. Further, testing such as UAT may be performed on this version of the product.

11. What are the most important components of Agile?

The key feature of agile are:

• Daily stand-up meetings.
• CRC (Class Responsibilities and Collaborators) cards timeboxed task boards.
• TDD (Test Driven Development), Continuous Integration, regular code reviews, pair programming, automated builds, continuous deployment, and delivery, etc.
• You have iteration planning meetings and carry out iterative development.

12. What are project management tools used in agile?

Agile has a new breed of PM tools including Rally Software, Version One and XPlanner, EasyBacklog, iceScrum, Agilefant, Agilo. These tools bear no resemblance to the waterfall PM tools like MS-Project or Clarity.

13. How can study Board be defined in agile?

A Story Board is a visual representation of a software project’s progress. There are generally four columns ‘To do’, In Progress’, ‘Test’, and ‘Done’. Different colored post, its notes are placed in each column indicating the progress of individual development items. A storyboard is typically used in agile development.

14. How much time should a person expect to spend on Scrum Master activities?

A Scrum Master should make this role their top priority to focus on benefits of the overall team. Their load will vary from sprint to sprint depending on what impediments and issues the team are dealing with. Newly formed teams typically take more Scrum Master time; 50%-100%, while experienced Scrum Masters with established well-functioning teams might spend 50% or less time on the Scrum Master role.

15. Why is the Scrum development less risky than waterfall method?

In Scrum, the focus is on delivering fully-tested, independent, valuable, small features. Thus, the risk is diversified and if one feature goes wrong, it should not impact another feature.

[read more=”Click here to Read More” less=”Read Less”]

16. What should be an ideal duration of a sprint?

It is recommended to have 2 – 4 weeks of sprint cycle.

17. How are requirements defined in a scrum?

Requirements are termed as “User Stories” in Scrum.

18. Name two techniques for prioritizing user stories?

• MoSCoW
• 100 Point Method.
  

19. What is Scrum Sprint?

A Scrum Sprint is a regular, repeated work cycle in scrum methodology during which work is completed and made ready for review. Scrum sprints are basic units of development in the scrum methodology. Generally, scrum sprints are less than 30 days long.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

No changes are made that would endanger the Sprint Goal.

Quality goals do not decrease, and the scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

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

Epic is a group of related user stories.

User Stories define the actual business requirement. Generally created by the business owner.

Task: To accomplish the business requirements, development team create tasks.

21. How is the velocity of sprint measured?

If capacity is measured as a percentage of 40 hours weeks then completed

= story points * team capacity

If capacity is measured in man hours then completed story points/team capacity.

22. How do you define a user story?

The user stories are defined in the format of

As a <User / type of user>

I want to <action / feature to implement>

So that < objective>

23. What are the roles of a Scrum Master and Product owner?

Scrum Master – Acts as a servant Leader for the scrum team. He presides over all the scrum ceremonies and coaches the team to understand and implement scrum values and principals.

Product Owner – Is the Point of contact for a scrum team. He/she is the one who works closest to the business. The main responsibility of a product owner is to identify and refine the product backlog items.

24. Explain what is a product backlog in Scrum?

Before the scrum sprint initiates, product owner reviews the list of all new features, change requests, enhancements and bug reports and determines the priority. If the project is new, it includes new features that the new system must provide- this list of the item is referred to as Product Backlog. The items that are kept on sprint are referred to as Sprint Backlog.

25. Explain Velocity in Agile?

Velocity is a metric that is calculated by addition of all efforts estimates associated with user stories completed in one iteration. It predicts how much work Agile can complete in a sprint and how much time will it require to complete a project.

26. How can tracer bullet be used?

Tracer bullet can be used as a spike with the current architecture or the current set of best practices. The purpose of a tracer bullet is to examine how an end-to-end process will work and examine feasibility.

• Tracer ammunition, which is a part of bullet built with a small pyrotechnic charge in their base
• It is a fictional detective, alter ego of Calvin in the comic strip Calvin and Hobbes
• It is used in Scrum (software development) to describe a proof-of-concept deliverable
• Pathfinder (library science) – a term for those pathfinders produced by the Library of Congress.
  

27. How can QA add value to an agile team?

QA can provide value addition by thinking differently about the various scenarios to test a story. They can provide quick feedback to the developers whether new functionality is working fine or not.

QA is not a separate silo but is part of a cross-functional project team. It is included in the project from the beginning, and the whole team works together on user stories using the same tracking tools. The Director of the QA team works closely with the executive management team to identify technology and staffing needs in relation to project pipelines.

Quality Assurance is empowered to support projects and add value in whatever way the situation requires. Examples include design reviews, requirements assessments, browser and device support, process, tools, risk assessments, and helping to determine “Definition of Ready” and “Definition of Done.”

QA sits with the project team whenever possible, allowing for increased conversation and problem-solving in real time. The QA team attends and contributes to all relevant planning meetings and sprint ceremonies and also work directly with clients on quality and testing processes.

Members of QA teams always learn as individuals, as project team members, and as representatives of a skilled discipline within the organization. Our process and approach to testing evolve to keep up with advances in technology and the changing needs of clients. What works for one client or project might differ radically from another. Flexibility is the key.

28. What does a scrum burndown chart comprise?

A scrum burndown chart should consist of:

X-axis that displays working days

Y-axis that displays remaining effort

Ideal effort as a guideline

Real progress of effort.

29. What are the artifacts of Scrum process?

Scrum process artifacts include:

Sprint backlog – The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

Product backlog – The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Velocity chart– A velocity chart shows the sum of estimates of the work delivered across all iterations. Typically, velocity will stabilize through the life of a project unless the project team make-up varies widely or the length of the iteration changes.

Burn-down chart – It is a chart that shows how quickly you and your team are burning through your customer’s user stories. It shows the total effort against the amount of work we deliver on each iteration.

30. Does maximum velocity mean maximum productivity?

No, in an attempt to maximize velocity, a team may, in fact, achieve the opposite. If asked to maximize velocity, a team may skimp on the unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize re-factoring. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact. The goal is not to maximize velocity instead of the optimal velocity over time, which takes into account many factors including quality of the end product.

31. How to measure velocity if our iteration lengths change?

You can’t measure it easily. Velocity’s value comes from its inherent consistency. A fixed iteration length helps drive the reliable rhythm of a project. Without this rhythm, you are constantly revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results.

If, on the other hand, almost everyone is going to be out a week for the holidays or a couple days for company-wide meetings then, by all means, adapt iteration dates or velocity accordingly. Like most agile practices, these are guidelines, not strict rules.

32. What do you know about impediments in Scrum? Give some examples of impediments.

Impediments are the obstacles or issues faced by scrum team which slow down their speed of work. If something is trying to block the scrum team from their getting work “Done” then it is an impediment. Impediments can come in any form. Some of the impediments are given as –

• Resource missing or sick team member
• Technical, operational, organizational problems
• Lack of management supportive system
• Business problems
• External issues such as weather, war etc
• Lack of skill or knowledge
• While answering impediments related agile scrum interview questions scrum master remember that you may be asked the way to remove any of the mentioned impediment.

33. What is the difference and similarity between Agile and Scrum?

Difference between Agile and Scrum – Agile is a broad spectrum, it is a methodology used for project management while Scrum is just a form of the Agile that describes the process and its steps more concisely. Agile is a practice whereas scrum is a procedure to pursue this practice.

The similarity between Agile and Scrum – The Agile involves completing projects in steps or incrementally. The Agile methodology is considered to be iterative in nature. Being a form of Agile, Scrum is same as that of the Agile. It is also incremental and iterative.

34. What is increment? Explain.

This is one of the commonly asked agile scrum interview questions and a quick answer can be given this way. An increment is the total of all the product backlogs items completed during a sprint. Each increment includes all the previous sprint increment values as it is cumulative. It must be in the available mode in the subsequent release as it is a step to reach your goal.

35. What is “build-breaker”?

The build-breaker is a situation that arises when there is a bug in the software. Due to this sudden unexpected bug, compilation process stops or execution fails or a warning is generated. The responsibility of the tester is then to get the software back to the normal working stage removing the bug.

36. What do you know about Scrum ban?

Scrum-ban is a Scrum and Kanban-based model for the software development. This model is specifically used for the projects that need continuous maintenance, have various programming errors or have some sudden changes. This model promotes the completion of a project in minimum time for a programming error or user story.

37. State some of the Agile quality strategies.

Some of the Agile quality strategies are –

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

38. Do you know about Agile Manifesto & its Principles? Explain in brief.

This is the theory which most of agile/scrum roles aspirant should be on tips. Four manifesto values and 12 principles should be explained as much as possible as part of this question. Even if it’s not explained in 100% accurate manner it should be fine but intentions of values and principles should come out.

e.g.:

• Working Software should be demonstrated at regular intervals
• Individuals & interaction – self-organization, self-motivating should be encouraged
  
• Customer collaboration
  
• Welcoming change at any point in time in the project.
  

39. Is there any drawback of the Agile model? If yes, explain.

Yes, there are some drawbacks of the Agile model, some of them are as follows –

• It is not easy to make a prediction about the effort required to complete a task. It becomes more problematic in case of large projects as it becomes difficult to get an idea of the total effort required.
• At sometimes, it’s not possible to properly focus on the design and documentation of the project
• In case the requirements of the client are not understood properly, the final project will not meet the customer requirements. Thus, it will lead to the customer dissatisfaction.
• Only the leader who has considerable experience in Agile methodologies is capable to take important decisions. The team members with little or no experience are not involved in decision-making, thus they don’t get chance to advance their knowledge.
• It’s not always the case that you will be asked the questions about the characteristics and advantages of the agile and scrum in an agile scrum interview. So, just prepare yourself for the drawbacks and disadvantages related to agile scrum interview questions.

40. What is the use of burn-up and burn-down charts?

The burn-up chart illustrates the amount of completed work in a project whereas the burn-down chart depicts the amount of work remained to complete a project. Thus, the burn-up and burn-down charts are used to trace the progress of a project. 

41. Define Zero Sprint and Spike in Agile.

To answer this question, describe Zero Sprint and Agile in detail, as follows –

 Zero sprint – Zero Sprint can be defined as the preparation step of the first sprint in Agile. There are some activities that are required to be done before actually starting the project. These activities are considered as the Zero sprint; the examples of such activities are – setting the environment for development, preparation of backlogs etc. 

Spike – Spike is the type of story that can be taken between the sprints. Spikes are commonly used for the activities related to the design or technical issues such as research, design, prototyping, and exploration. There are two types of spikes – functional spikes and technical spikes.

42. What is the role of the Scrum Master?

Here’s how you can answer Scrum Master interview questions like this – 

The scrum master is the leader as well as coach of the Scrum team. The scrum master is responsible to serve and protect his team from any kind of distractions that could affect their performance. The main role of the scrum master is to motivate his team to achieve the sprint goal. He is focused to build a self-organized and motivated team where each member is familiar with the implementation of Agile and Scrum principles and applications. The scrum master keeps a proper check on the scrum team if they are executing committed tasks properly. He is also responsible to increase the efficiency and productivity of the team so that they can achieve the sprint goal effectively.

43. What are the responsibilities of a Scrum Master?

Key responsibilities of a Scrum Master involve: 

• Tracking and monitoring 
• Understanding requirements properly 
• Work to reach the project goal 
• Process checking master and quality master 
• Protect the team from detachments 
• Improving the performance of the team 
• Lead the meetings and resolve issues 
• Resolution of conflicts and impediments 
• Communication and reporting.

44. What are the different roles in Scrum?

The three scrum roles i.e. Scrum Master, Product Owner and Team should be explained with the details of few primary responsibilities of each role. You can add more details as mentioned below for a particular depending on the role you are getting interviewed for. 

Product owner – A product owner is actually the stakeholder of the project. He represents the project requirements before the team. He is responsible to have a vision of what to build and convey his detailed vision to the team. He is the starting point of an agile scrum software development project. 

Scrum team – Scrum team is formed by the collective contribution of individuals who perform for the accomplishment of a particular project. The team is bound to work for the timely delivery of the requested product. 

Scrum master – Scrum master is the leader and the coach for the scrum team who checks whether the scrum team is executing committed tasks properly. He is also responsible to increase the efficiency and productivity of the team so that they can achieve the sprint goal effectively.

45. What is the role of Sashimi in Scrum methodology?

Sashimi plays an important role in Scrum methodology. Sashimi is a technique used by Scrum to check the completion of all the functions created by the developers. Using this technique, all the requirements such as analysis, designing, coding, testing and documentation that are used in the constitution of a product are checked and only after that the product is displayed.

46. What do you understand by the term Agile testing?

Agile testing is a software testing practice that is fully based on the agile principles of software development. It is an iterative methodology where the requirements are the outcome of collaboration between the product owner and team. The agile principles and applications are applied to meet the customer requirements by successful completion of the project.

47.State some major principles of Agile testing.

• Customer satisfaction 
• Face to face communication 
• Sustainable development 
• Quick respond to changes 
• Continuous feedback 
• Successive improvement 
• Self-organized 
• Focus on essence 
• Error-free clean node 
• Collective work

48. What are the skills of a good Agile Tester?

An agile tester is one who implements agile software development principles for software testing. Followings are the skills of a good agile tester – 

• Required to be familiar with the concepts and principles of Agile 
• Should have an excellent communication to communicate with the team and the clients 
• Ability to set priority for the tasks according to the requirements 
• Should be able to understand the requirements properly 
• Understanding of the risks involved with a project due to changing requirements.

49. Explain what is scrum of scrum?

Scrum of scrum is used to refer the meeting after the daily scrum. The responsible person from each team attends the meeting and discuss their work and answer the questions like:

• Since the last meeting, what is the progress of the team?
• What your team is expected to do or should accomplish, before the next meeting?
• What are the obstacles your team faced while completing the task?
• Were you going to allot any of your work to the following team?

50. Explain some common matrices for Agile.

You may definitely come across agile scrum interview questions regarding agile matrices. The question may be related to a particular agile matric or explaining all the matrices. So, the detailed description of some common matrices for Agile is as follows: 

Velocity – Velocity is the average number of points from last 3-4 sprints. It is measured by the summation of the all approved estimates of the stories. It gives an idea of the capacity, progress etc. 

Cumulative Flow Diagram – With the help of cumulative flow diagram, an inspection is done over the uniform workflow. In this diagram/graph, the x-axis represents time whereas the y-axis represents the number of efforts. 

Work Category Allocation – Work category allocation is an important factor that gives a quick information of the time investment i.e. where the time is being invested and which task should be given priority as a factor of time. 

Time Coverage – It is the time that is given to a code during testing. It is calculated in percentage as a factor of the number of lines of code called by test suite and the total number of relative lines of code. 

Business Value Delivered – It is a term which denotes the working efficiency of the team. The business objectives are assigned numerical values 1,2,3.. and so on, as per the level of priority, complexity, and ROI. 

Defect Removal Awareness – It is the factor that helps the team to deliver a quality product. The identification of an active number of defects, their awareness, and removal plays an important role in delivering a high-quality product. 

Defect Resolution Time – It is a procedure through which the team members detect the defects (bugs) and set a priority for the defect resolution. The procedure of fixing errors/bugs or defect resolution comprises of multiple processes such as clearing the picture of defect, schedule defect fixation, completing defect fixation, generation, and handling of resolution report. 

Sprint Burn Down Matric – The sprint burndown chart is a graph to represent the number of non-implemented or implemented sprints during as Scrum cycle. This matric helps to track the work completed with the sprint.

51. Is it ever suggested to use waterfall over Scrum? If yes, explain when.

Yes, sometimes it is suggested to use waterfall model over Scrum. It is done when the customer requirements are simple, well-defined, fully understood, predictable, and are not subjected to change until the completion of the project. It may the case that you would haven’t ever used waterfall over Scrum but you need to prepare for such Agile Scrum interview questions.

52. Why does Scrum encourage the use of automated testing for projects?

Scrum encourages the use of automated (automated performance or automated regression) testing to make the fastest possible delivery of the project. While answering this question, you may explain some tools that you have used for the automated testing.

53. What do you know about “Planning Poker” technique?

Planning poker, also known as Scrum Poker, is a card-based agile technique that is used for planning and estimation. To start a session of planning poker technique, the agile user story is read by the product owner. The steps performed in the poker planning technique are – 

• Each estimator has a deck of poker cards with the values such as 0, 1, 2, 3, 5, and so on, to denote story points, ideal days or something else that the team uses for estimation.
• Each estimator has a discussion with the product owner and then privately selects a card on the basis of their independent estimation. 
• If the cards with same value are selected by all estimators, it is considered as an estimate. If not, the estimator discusses the high and low value of their estimates. 
• Then again, each estimator privately selects a card and reveals. This process of poker planning is repeated to reach a general agreement.

54. Name some methodologies and development where you have used Agile model.

While answering this type of agile scrum interview questions, keep in mind to mention those methodologies that are familiar with. Some of the methodologies and development where Agile model can be used are – 

• Crystal methodologies 
• Lean software development 
• Dynamic development 
• Feature-driven development

55. What is the biggest challenge you faced in your project while handling the Scrum team members?

This question is pure to judge your experience. The better you articulate your challenges working in agile better it will be. Challenges generally faced in the initial stages of scrum is stabilizing the velocity, team members conflicts, sticking to time-boxing etc.

56. Have you ever performed the removal of impediments as a scrum master on behalf of scrum team?

As the scrum master acts as a coach for his team, he should motivate his team to perform every task. Although he can remove impediments on behalf of scrum team but he should not do this. It is recommended for a scrum master not to over pamper nor overrule the team. There may be something when the team can face failure, at that time the scrum master should help them. He should guide them with an appropriate method t0 get out of the problem. Scrum master should prompt his team members to become independent enough to face problems and take a decision by themselves. This is one of the frequently asked scrum master interview questions, so prepare now and get ready to answer.

57. What is the difference between the agile & traditional way of working?

This question is to judge whether one is aware of the environment of the agile way of working. Here the answer is expected to cover few or all of below: 

• Traditional way is sequential where design->Development->Testing etc. happens one after another whereas in agile all of this is done in every iteration/sprint.
• Changes are welcomed in agile as Scope is flexible whereas in traditional manner scope is fixed in the beginning due to which changes have to follow change request path. 
• Progress is measured with % completion traditionally whereas working software is the measure of progress in agile. 
• Project Manager as a central controlling authority is traditionally driving the project whereas Self-motivated and self-organizing teams drive the projects in agile.

58. What is the difference between Sprint Planning Meeting and Sprint Retrospective Meeting?

The difference between Sprint Planning Meeting and Sprint Retrospective Meeting is as follows:

Sprint Planning Meeting – A meeting in which all the Scrum roles (product owner, scrum team, and scrum master) have a discussion about the team’s priority features and product backlog items is known as sprint planning meeting. This meeting is held every week and lasts for almost 1 hour. 

Sprint Retrospective Meeting – A meeting in which all the Scrum roles (product owner, scrum team, and scrum master) have a discussion about the good part of the sprint, the bad part of the sprint, and the sprint improvements is known as sprint retrospective meeting. This meeting that is held at the sprint review meeting or at the end of the sprint; it lasts for 2-3 hours. 

This is one of the frequently asked Agile Scrum interview questions. You may be asked to define the above terms separately or the difference between these two.

59. How is agile testing methodology different from other testing methodologies?

Agile scrum interview questions may include a number of questions from agile testing. Let’s understand how you can answer such questions. 

The agile testing methodology involves the division of whole testing process into multiple small segments of codes. In every step, these segments of codes undergo testing. There are a number of additional processes involved in agile testing methodologies such as team communication, strategic modifications for optimal results and many others.

60. Do you hold any agile certification? Why did you choose this certification?

Agile and scrum certifications are hot in market and organizations are expecting the candidates to hold one or more out of it. Certifications generally looked by organizations are: 

• ACP (Agile Certified Practitioner) 
• ASM (Agile Scrum Master) 
• CSM (Certified Scrum Master) 
• PSM (Professional Scrum Master) 
• SAFe Agilist 

If you have any of these certifications, showcase it here in a big manner. Due to many options available in the market, organizations also have started asking why you have chosen one. It’s recommended that for your certification you know few good points as its advantages handy with you so that it can be mentioned once asked.

61. Do you have a Scrum Master certification?

This question may seem awkward to you but it is one of the most popular Agile Scrum interview questions. If an interviewer asks this question, it doesn’t mean that a certification is must for the job position. Just be confident while answering whether you have a scrum master certification or not. If you are a certified scrum master, just share the details of your certification like certification exam, score obtained, and the year of passing the certification exam. In case you don’t have a certification, mention and highlight your experience in the particular field. Also, let the interviewer know if you are planning to invest in the certification in the near future.

62. How do you ensure that the Scrum team has an access to the stakeholders?

Here are some of the ways the Scrum team can have access to the stakeholders: 

• Get support from the stakeholders themselves 
• Educate senior management 
• Be flexible 
• Be prepared to work with stakeholder representatives 
• Be proactive and present a plan to prove your capabilities.

63. During Scrum meeting what all things are done?

During scrum meeting,

• Team analyze how much time they got to complete task during the Sprint
• From product backlog, team takes the first item and breaks into tasks 
• Team estimates how long a task will take 
• If there is any time left during the sprint, they will move on to the next item on the product backlog Decide the features which have clarity and estimates how many to be scoped for sprint.

64. Explain what is “Sashimi” and “Impediments”?

Sashimi: This term is analogous to “done”, it is used to define the specific task when it is completed. The term used by different team to refer their completed task status may differ, but should remain same within one team. 

Impediments: Any obstacle that prevent the team members from performing their work is referred as impediments.

65. Explain what does the burn down charts show?

Burn down charts is used to track sprint status, they act as an early warning indicator, they can be useful in highlighting the “lack of progress”. Also, they will highlight the area where they see redundancy.

66. Mention what is the objective behind holding a Sprint retrospective meeting?

The objective behind Sprint retrospective meeting is to let team members know how things went during the sprint and discuss possible ways for further improvements for future sprints.

67. Mention what is the difference between Sprint and Iteration in Scrum?

Iteration: It is a terminology used to define single development cycle in general agile methods. It is a common term used in the iterative and Incremental development process.

Sprint: It is used to define one development cycle or iterative step in a specialized agile method referred as Scrum. Sprint is scrum specific, and not all forms of iterations are Sprints.

68. Explain What is a story point in scrum?

Each feature in scrum is Story. Story point is an arbitrary measure used by Scrum teams, and it is a metric used by agile teams to determine the difficulty of implementing a given story.

69. Explain when Scrum cannot be useful?

Ideally scrum is useful to monitor work with 5 to 10 people, who are committed to achieving the sprint goal. It does not go well with huge groups or team having more responsibilities. For larger team, scrum can be applied by splitting the team into small groups and practice scrum. 

70. The Agile Manifesto says “people over processes”. Isn’t the Scrum Master, a role meant to enforce the process, therefore a contradiction?

A Scrum Master does not wield any real authority; the scrum team does not report to them. This question, therefore, is meant to discern whether the candidate understands that their role is to lead — as opposed to manage — the team. This question should also help to discern why a candidate is interested in the role of a Scrum Master in the first place. Acceptable answers include: 

• I am the facilitator for the scrum team. It’s my job to make them successful. 
• I am neither a project manager, nor a people manager. I remove impediments, but I do not tell people what to do. 
• I am the scrum team’s coach, encouraging them to excel as an agile team.

71. Are there any common metrics that you would track? If so, which metrics would you track and for what purpose?

This question is, in part, a subset of the previous question. However, and especially when concerning the change management process itself, there are effects that could be measured with a scoring model. Some of these effects are: 

• The ability to respond to change and produce valuable code. In other words: the ability to break down features. 
• The duality of planning at both release and sprint level. 
• The flexibility to adapt to changing facts, time boxes, and continuous delivery. 
• That teams are bidding on stories and have the freedom to select their approach to solving them. 
• The creation of a culture of shared learning, and the continuous demonstration of features delivered. In order to capture these developments, a scoring model can be devised based on the agile maturity in the organization so that these qualitative aspects can be quantified and thus compared. 

Usually — before introducing an agile framework within an organization — it is useful to gather the status quo (the baseline) of these dimensions and review their evolution through time. 

These metrics should be continuously addressed throughout the agile journey (via surveys with team members in agile departments, for example).

72. Your team is constantly failing to meet commitments, and its performance velocity is volatile. What might the possible reasons be? How would you address this issue?

This question addresses various issues. There are many possible factors that might combine to make a team’s velocity volatile. Such factors might include: 

• New team members are being onboarded 
• Team members are leaving 
• Levels of seniority 
• Working in uncharted territory 
• Working with legacy code, probably undocumented 
• Unexpected technical debt 
• Holidays and sick leave 
• Executive intervention 

If the team’s commitment is frequently too aggressive, this could indicate that user stories are poorly prepared — e.g. the definition of ready is not met — which makes the stories hard to estimate. Conversely, their projects might suffer from poorly documented legacy code, excessive technical debt, or just too much buggy and poorly written code — all of which make estimation very hard. 

Organizations must be vigilant and not fall for the fallacy that agile is working because commitment and velocity are aligned. Cooking the agile books is easy to do!

73. How do you spread an agile mindset across different departments and throughout a company, and what is your strategy when coaching non-IT stakeholders?

There are various ways of engaging stakeholders with scrum: 

•  Product and Engineering teams can produce evidence, in presentations or otherwise, proving to stakeholders that scrum is significantly reducing the lead time from idea to product launch. 
• Product and Engineering teams can demonstrate that scrum mitigates risk, e.g. regarding the prediction of when new features could be made available, thus contributing to other departments’ successes in planning and execution. 
• A scrum team can be transparent with respect to their work and proactively engage stakeholders by inviting them to meetings, sprint demos, and other events where the team communicates their activity or progress
• One hands-on approach is to organize workshops designed to teach agile techniques for non-technical colleagues.

74. How would you introduce scrum to senior executives?

This is a deliberately open question meant to encourage discussion. The candidate should be concerned with how to spread an agile mindset throughout an organization, or, more particularly, how to create a learning organization that embraces experimentation in order to identify the best product for its customers. 

• Practical considerations might include organizing workshops for C-level management — applying scrum at the executive level has been successful in the past. 
• Executives — and even, potentially, key directors — can gain first-hand experience with agile methodologies if organized as a scrum team. 
• There are no answers to this question easily labelled “right” or “wrong”. Best practices will — and should be — tied to an organization’s culture, size, and the industry it’s operating in.

75. You’ve already provided your project’s stakeholders with training in scrum. After the initial phase of trying to apply the concepts, when the very first obstacles are encountered, some of these stakeholders begin to resist continued adoption. What is your strategy for and experience in handling these situations?

This is another open question, meant to encourage an exchange of ideas about and lessons learned when overcoming resistance to agile within an organization. Familiarity with agile failure patterns common in many organizations will demonstrate a candidate's experience — we have published a list of agile failure patterns at Age of Product.

76. The product owner for your team normally turns stakeholder requirements documents into tickets and asks you to estimate each. Are you okay with that procedure?

A Scrum Master should not accept such a procedure, as it’s nothing more than a waterfall process dressed-up in a pseudo-agile methodology. If the entire organization is supposed to focus on delivering value to its customers, it is essential that any process involving “requirements” being handed down to the engineers by a JIRA monkey be abandoned. Instead, the organization should start including everyone in the product discovery process — thereby establishing a shared understanding of what needs to be built.

77. What kind of information would you require from the product owner to provide your team with an update on the product and market situation?

Any information suitable to provide the team, with an understanding why something is of value to customers. This may be of a quantitative nature, e.g. analytical data describing how a process is utilized. It also may be of a qualitative nature, such as transcripts, screencasts, or videos from a user testing session.

78. What does a good user story look like? What is its structure?

A good user story:

• has a description,
• defines acceptance criteria, 
• can be delivered within a single sprint, 
• has all UI deliverables available? 
• has all (probable) dependencies identified, 
• defines performance criteria, 
• defines tracking criteria, and
• is estimated by the team.

79. What should a “Definition of Ready” consist of?

A “Definition of Ready” is an agreement between the scrum team and the product owner about what must be included in a user story before the story can be considered ready for estimation. It defines what a good user story looks like. Another approach, however, is to use a framework for how we think about user stories. One such framework is the INVEST mnemonic by Bill Wake, which specifies:

 Independent: The user story should be self-contained, in a way that there is no inherent dependency on another user story.

Negotiable: User stories, until they become part of an iteration, can always be changed and rewritten. Valuable: A user story must deliver value to the end user. 

Estimable: You must always be able to estimate the size of a user story. 

Small: User stories should not be so big as to become impossible to plan, task, and prioritize with a certain level of certainty. 

Testable: The user story or its related description must provide the necessary information to make test development possible.

80. Why aren’t user stories simply estimated in man-hours?

It's okay to use hours instead of points when the team and the organization can deal with it. However, some organizations will fall back into waterfall planning when work is estimated in hours. 

Estimating in hours might also be tricky when: 

• legacy software is involved, 
• the team is facing significant technical debt, or
• a team is composed of mostly junior members. 

Story points are more suitable in these situations because the points more accurately reflect both required effort and complexity. This is a result of points being used not only for estimation, but also as a means to measure and convey commitments and team velocity.

81.The product owner of your scrum team tends to add ideas of all kinds to the backlog so to remember to work on them at a later stage. Over time, this has led to over 200 tickets in various stages. What’s your take on this? Can a scrum team work on 200 tickets?

Any product backlog larger than the scope of two or three sprints is not manageable. Misusing a backlog by adding hundreds of items to it is a clear sign that the product owner needs help from the team to cope with the influx of ideas, suggestions, and requirements — and avoid misallocating resources. This support is what the candidate should offer.

82. How can you as a Scrum Master contribute to sprint planning in such a way that the team is working only on the most valuable user stories?

The scrum team should never select user stories according to any kind of ranking established by the product owner or anyone else. Sprint planning is determining the most efficient path to value creation. The best way to accomplish this is to ensure that:

• The scrum team is involved in the product discovery process at an early stage. 
• The product backlog refinement process is well understood by both the scrum team and the product owner. (This can be supported, for example, by the creation of a “Definition of Ready” standard for user stories.) 
• All user stories are created in a collaborative effort between the product owner and the scrum team. (A shared understanding and joint ownership is the goal.)

83. How do you facilitate user story selection in a way that the most valuable stories are chosen without overruling the team’s prerogative to define their own commitments?

If a team is involved early enough in the process, for example by jointly creating user stories with the product owner, or during product discovery, any kind of guidance will be unnecessary. Most teams will often autonomously pick the best user stories for a given sprint. If a team resorts to “cherry picking” user stories during sprint planning, however, then the backlog refinement process needs to be seriously addressed, as the product owner is likely picking user stories that are not maximizing customer value.

84. How much capacity would you consider adequate for refactoring? Fixing important bugs? Exploring new technologies or ideas?

Setting aside the most critical and urgent tasks (such as the web site being offline), the 15–10–5 approach is generally a good rule of thumb: dedicate 15% of a team’s capacity to technical debt, 10% to bugs, and 5% to explorative spikes. You may, of course, deviate from this when it comes to an individual sprint. But, generally, maintaining these allocations will satisfy the maintenance requirements of most software applications.

85. How do you deal with a product owner that assigns user stories or tasks to individual team members?

Assigning tasks to individual team members does not work at all and needs to be stopped. The assignment of user stories is the scrum team’s prerogative. Preventing individual task assignment, if likely to occur, should be one of the Scrum Master’s most pressing concerns.

86. How do you deal with team members “cherry picking” tasks?

A scrum team should generally have autonomy in how its members choose to distribute tasks. Maybe the presumed “cherry picking” of tasks by individual team members is a crucial part of the team’s path to performance. 

However, if team members complain about this happening, the scrum master needs to address the issue. Additional training might enable some team members to accommodate a greater variety of tasks. Or, perhaps, someone needs to be gently pushed out of their comfort zone so that they learn to choose different kinds of tasks than the kinds they currently choose.

87. A user story is lacking the final designs, but the design department promises to deliver on day two of the upcoming sprint. The product owner of your scrum team is fine with that and pushed to have the user story put in the sprint backlog. What’s your take?

The answer to this depends upon the team’s situation and experience: If the design department will definitely deliver (because they have done so in the past); if the user story is high value and can be accomplished within the sprint despite its UI deliverables arriving late; and if the team agrees — it’s probably an acceptable exception.

Beware, however, that this kind of exception does not become the “new normal” — allowing the organization to bypass the backlog refinement and sprint planning process. The candidate should be aware that such a situation would not be tenable. 

Furthermore, if implementation of a user story subjected to such an exception fails, no one will bother to read the fine print and acknowledge that an exception had been made; instead, they will most likely view the agile process itself as having failed.

Candidates may either accept or reject exceptions to the agile process, but they should be able to analyse the situation and explain the collateral damage that the scrum team may be exposed to.

88. A member of the scrum team does not want to participate in the sprint planning and considers the meetings a waste of time. How do you deal with this attitude?

This kind of passive–aggressive behaviour is not necessarily a problem particular to scrum. It is, however, toxic, and will affect both team-building and performance. If a member of a scrum team is behaving in this way, the Scrum Master will need to take action, as such behaviour can neither be ignored nor tolerated if the team is to continue functioning. Dealing with it may require an escalating approach:

• As a first step, the Scrum Master might address the team member privately to discuss their reservations. Perhaps they just need more coaching or a longer training period to change their attitude. 
• As a second step, the entire team could make it an issue during one or more retrospectives — and offer support to the team member. 
• If there is still no change of attitude, a meeting with the team member and his or her manager is advisable. 
• Finally, if no change can be achieved, the team member should be reassigned — potentially to another, probably non-agile team. Alternatively, a kanban team that would not force the team member out of their comfort zone could be tried. Scrum is not meant for everybody.

89. Would you recommend formal standups for all teams no matter their size or experience level?

In answering this question, the candidate should exhibit common sense. Standups are an important part of scrum, but not all standups need to be formal. A small, experienced, collocated team may use a coffee break for their standup. However, taking that kind of relaxed approach to standups for a large team with several junior members would probably achieve nothing if it doesn't first descend into chaos. For large teams, a formal meeting is needed to provide format and guidance. For distributed teams who need to “dial in” and, for obvious reasons, can't meet for coffee, a formal standup is necessary insofar as the standup, due to technical constraints, must be scheduled and conducted in an organized fashion.

90. Do you expect experienced team members to wait until the next standup to ask for help overcoming an impediment?

Certainly not. Waiting for the next standup delays progress. When facing impediments, if team members are waiting for the next standup before asking for help, it's likely that the “team” is more of a group — and the scrum master has team-building work to do.

91. How do you handle team members that “lead” standups, turning the event into a reporting session for themselves?

All teams go through Tuckman’s stages of group development: norming, storming, forming, performing. Scrum teams included. 

Although there are not officially any leadership roles within a scrum team, someone is likely to assume that role. This might happen because of his or her (technical) expertise, communication skills, or level of engagement. It’s important, however, that this does not result in other team members reporting to this person. The Scrum Master must therefore be vigilant and intervene if necessary to ensure team members communicate — during standups or otherwise — as required by scrum.

92. How do you manage team members that consider standups to be a waste of time and who are therefore either late, uncooperative, or who simply don’t attend?

The kind of passive–aggressive behaviour depicted by this question is not necessarily a problem particular to scrum. It is, however, toxic, and will affect both teambuilding and performance. If a member of a scrum team is exhibiting such an attitude, the scrum master will need to take action. Such behaviour can neither be ignored nor tolerated if the team is to continue functioning. Dealing with it may require an escalating approach: 

•  As a first step, the Scrum Master might address the team member privately to discuss their reservations. Perhaps they just need more coaching or a longer training period to change their attitude. 
• As a second step, the entire team could make it an issue during one or more retrospectives — and offer support to the team member. 
• If there is still no change of attitude, a meeting with the team member and his or her manager is advisable. 
• Finally, if no change can be achieved, the team member should be reassigned — potentially to another, probably non-agile team. Alternatively, a kanban team that would not force the team member out of their comfort zone could be tried. Scrum is not meant for everybody.

93. The standups of your scrum team are not attended by any stakeholder. How do you change that?

This can quickly turn into a philosophical discussion. Should stakeholders be allowed to participate in daily scrums? If they do, is it a form of reporting — circumventing scrum rules? 

If some adaptation of scrum is working in your organization — that’s a good thing. 

Don’t rule out stakeholders being allowed to participate in the daily standups if the team is okay with that. In fact, if stakeholders attend standups regularly, this will invariably and significantly improve communication between the team and the stakeholders — another good thing.

But how does a Scrum Master encourage stakeholders to attend standups? Make it worth their while. A Scrum Master can do this in any number of ways. They might offer stakeholders the opportunity to learn early details of a new product or feature if they attend. They might also choose to give stakeholders the opportunity to ask questions of the engineers directly, without going through the product owner.

94. How do you approach standups with distributed teams?

Standups with distributed teams are not much different to standups with colocated teams — except that sharing board activity may require video conferencing when the team is working with offline boards that mirror each other. 

If you are using task management or planning software like JIRA (or any other cloud-based application), board updates are generally easy for each team member to follow on-screen. With such online software in place, a Skype call or Google Hangout may suffice.

95. Can you draw an example of an offline kanban board for a scrum team right now?

The qualifier “kanban” is, of course, a teaser. But any Scrum Master should be able to draw a simple board. The necessary elements of any board are columns (or rows) for: 

• Backlog 
• In progress 
• Code review 
• Quality assurance 
• Done 

Additional information may be included on or attached to any kind of board: 

• Sprint or meeting dates 
• User Acceptance Tests (UAT) 
• A Definition of Ready 
• A burndown chart (progress and work remaining over time) 
• A parking lot (topics for future discussion).

96. Who should participate in a retrospective?

Although not mandatory, it's generally best practice to include the product owner in retrospectives — they are an important part of the “team”, both practically and functionally. Some scrum teams, however, may not always want their product owners to participate — a team’s wishes should be considered. Anyone else outside of the immediate scrum team, and particularly managers of team members, should not be invited to participate.

97. Do you check the team’s health during a retrospective, or is doing so unnecessary? If you do, how would you go about it?

Measuring a team’s health is a good way to get an idea about current levels of engagement and satisfaction and is a useful method for discerning trends. A simple scale from 1 (terrible) through 2 (poor), 3 (neutral), 4 (good), to 5 (excellent) will do the job — and requires just two minutes to complete.

98.What retrospective formats have you used in the past?

With retrospectives, one size does not fit all. Consequently, there are various retrospective formats in common use: 

The classic format: 

• What did we do well? 
• What should we have done better? 

The boat format: 

• What’s pushing us forward? 
• What’s holding us back? 

The starfish retrospective: 

• Start doing … 
• Do less of … 
• Do more of … 
• Stop doing … 
• Continue doing … 

Each serves different situations. The candidate should have applied more than one of these formats in the past and be able to share their reasons for having done so.

99. How do you prevent boredom during retrospectives?

Any of numerous possible variations may be used to prevent boredom during retrospectives. A different location; a different format; shortening or lengthening the allotted time box. Scrum masters can also use the team’s choice of action items to encourage and structure discussions around the issues that the team themselves thus identified — creating engagement through acknowledgement. 

There is no single correct answer to this question. What’s important is that the candidate acknowledges that boredom might become an issue, and that there are ways to deal with it.

100. Your team is picking reasonable action items but is later not delivering on them. How do you handle this?

If action items are picked but no one is later delivering on their commitments, the Scrum Master needs to follow up. 

If this is happening because of some impediment external to the team, the Scrum Master needs to address and eliminate the cause. The team can then catch up during a later sprint. 

However, if there is no external impediment, the problem is likely due to motivation, attitude, or personal issues within the team. In this latter case, the Scrum Master needs to provide those team members responsible with the encouragement or motivation necessary to overcome the problem and see that they deliver on their commitments. 

If the problem cannot ultimately be resolved, picking action items becomes a useless exercise — and the team will suffer as a result.

101. How would you recommend following-up on action items?

A good follow-up practice is to start talking about the status of the action items of the last retrospective — before picking new ones. If actions item from the last retrospective haven’t been accomplished, the scrum team needs to understand why they failed and prevent that failure from happening again.

102. How do you measure the work done in a sprint?

It’s measured by Velocity.

103. So in scrum which entity is responsible for deliverable? Scrum master or Product owner?

Neither the scrum master, not the product owner. It’s the responsibility of the team who owns the deliverable.

104. How do you measure the complexity or effort in a sprint? Is there a way to determine and represent it?

Complexity and effort is measured through “Story Points”. In scrum it’s recommended to use Fibonacci series to represent it.

105. How do you track your progress in a sprint?

The progress is tracked by a “Burn-Down chart”.

106. What do you do in a sprint review and retrospective?

During Sprint review we walkthrough and demonstrate the feature or story implemented by the scrum team to the stake holders. 

During retrospective, we try to identify in a collaborative way what went well, what could be done better and action items to have continuous improvement.

107. Do you see any disadvantage of using scrum?

I don’t see any disadvantage of using scrum. The problems mainly arise when the scrum team do not either understand the values and principles of scrum or are not flexible enough to change. 

108. Do you think scrum can be implemented in all the software development process?

Scrum is used mainly for:

• Complex kind of project 
• Projects which have early and strict deadlines
• When we are developing any software from scratch.

109. During review, suppose the product owner or stakeholder does not agree to the feature you implemented what would you do?

First thing we will not mark the story as done. 

We will first confirm the actual requirement from the stakeholder and update the user story and put it into backlog. Based on the priority, we would be pulling the story in next sprint.

110. In case, the scrum master is not available, would you still conduct the daily stand up meeting?

Yes, we can very well go ahead and do our daily stand up meeting.

111. Where does automation fit into scrum?

Automation plays a vital role in Scrum. In order to have continuous feedback and ensure a quality deliverable we should try to implement TDD, BDD and ATDD approach during our development. Automation in scrum is not only related to testing but it is for all aspect of software development. As I said before introducing TDD, BDD and ATDD will speed up our development process along with maintaining the quality standards; automating the build and deployment process will also speed up the feature availability in different environment – QA to production. As far as testing is concerned, regression testing should be the one that will have most attention. With progress of every sprint, the regression suit keeps on increasing and it becomes practically very challenging to execute the regression suit manually for every sprint. Because we have the sprint duration of 2 – 4 weeks, automating it would be imperial.

112. Apart from planning, review and retrospective, do you know any other ceremony in scrum?

We have the Product backlog refinement meeting (backlog grooming meeting) where the team, scrum master and product owner meets to understand the business requirements, splits it into user stories, and estimating it.

113. Can you give an example of where scrum cannot be implemented? In that case what do you suggest?

Scrum can be implemented in all kinds of projects. It is not only applicable to software but is also implemented successfully in mechanical and engineering projects.

114. Tell me one big advantage of using scrum?

The major advantage which I feel is – Early feedback and producing the Minimal Viable Product to the stakeholders.

115. What is DoD? How is this achieved?

DoD stands for Definition of done. It is achieved when the story is development complete, QA complete, the story meets and satisfy the acceptance criteria regression around the story is complete the feature is eligible to be shipped / deployed in production.

116. What is MVP in scrum?

A Minimum Viable Product is a product which has just the bare minimum required feature which can be demonstrated to the stakeholders and is eligible to be shipped to production.

117. What are Epics?

Epics are equivocal user stories or we can say these are the user stories which are not defined and are kept for future sprints.

118. How do you calculate a story point?

A Story point is calculated by taking into the consideration the development effort+ testing effort + resolving dependencies and other factors that would require to complete a story.

119. Is it possible that you come across different story point for development and testing efforts? In that case how do you resolve this conflict?

Yes, this is a very common scenario. There may be a chance that the story point given by the development team is, say 3 but the tester gives it 5. In that case both the developer and tester have to justify their story point, have discussion in the meeting and collaborate to conclude a common story point.

120. You are in the middle of a sprint and suddenly the product owner comes with a new requirement, what will you do?

In ideal case, the requirement becomes a story and moves to the backlog. Then based on the priority, team can take it up in the next sprint. But if the priority of the requirement is really high, then the team will have to accommodate it in the sprint but it has to very well communicated to the stakeholder that incorporating a story in the middle of the sprint may result in spilling over few stories to the next sprint.

121. In case you receive a story at the last day of the sprint to test and you find there are defects, what will you do? Will you mark the story to done?

A story is done only when it is development complete + QA complete + acceptance criteria is met + it is eligible to be shipped into production. In this case if there are defects, the story is partially done and not completely done, so I will spill it over to next sprint.

122. What is characteristics of Dev Team in Scrum?

Characteristics of Dev Team in Scrum are as follows: 

• Dev Team should be 7+/-2 people 
• Dev Team is cross functional 
• Dev Team is self-organizing.

123. What is role and responsibility of Product Owner?

• Product Owner is responsible for maximizing value of work done by Dev Team 
• Product Owner owns vision and goals / Return of Investment of work done
• Product Owner is final decision maker of list of items in Product Backlog 
• Product Owner owns date and scope of release

124. Define Extreme Programming(XP)?

It is a type of agile software development. It advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels. XP addresses the analysis, development, and test phases with novel approaches that make a substantial difference to the quality of the end-product. It is a type of agile software development. It advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels. XP addresses the analysis, development, and test phases with novel approaches that make a substantial difference to the quality of the end-product.

125. How is Agile different from waterfall?

Below give few key differences between Agile and Waterfall 

• In Waterfall work is done sequentially i.e. previous phase must be over before initiating next phase (Requirement, Design, Development, testing etc.) whereas in agile all of these are done in every iteration/sprint. 
• Feedback from customer/end user is received at a later stage (towards end of the development cycle) where as in agile feedback from customer is received continuously. 
• Requirements should be finalized before initiating development activities. Once requirements are locked down, changes are done through change requests whereas in agile changes are welcomed at all stages. 
• In waterfall, Progress is measured as percentage completion where as in agile progress is measured by working software. 
• In waterfall decision making or controlling authority is in the hand of project manager whereas in agile Self-motivated and self-organizing teams drives the projects.

126. Agile manifesto is ignoring process and tools, documentation, contract & planning. Do you think as a scrum master this is a correct approach?

The keyword over in all these manifesto statements. Manifesto is not suggesting to replace the items in right with left rather it stress upon prioritizing left items over right. 

• Individuals and Interactions over Processes and Tools. 
• Working Software over Comprehensive Documentation. 
• Customer Collaboration over Contract Negotiation. 
• Responding to Change over Following a Plan.

127. What are the advantages of Agile over Waterfall?

Below are few key advantages of Agile over waterfall 

• It minimizes the risk in response to changes made to the system & increases return of investment by reducing waste. 
• Achieve Customer satisfaction by early and continuous delivery of useful software (time to market) 
• Agile mindset & culture will help people to work as a united team (eventually they will be more committed & feel accountable for what they are doing) 
• Working software is delivered frequently (weeks rather than months) 
• Close & daily cooperation between business and IT team improves collaboration 
• Sustainable development pace helps your team continuously engaged & motivated 
• Focus on Improving Quality via Definition of Done, Team Working Cadence, Acceptance Criteria, INVEST 
• Focus on Continuous Improvement via regular feedback cycles (retrospective)

128. How to measure if Agile is working in your team and organization?

Few indications are 

• Increasing velocity of team & continuous Improvement 
• An increase in software quality (less technical debt, less bugs, and generally better maintainability).
• Increased participation of stakeholders in agile meetings, for example, during the sprint demo. 
• Working software delivered frequently (weeks rather than months).

129. How is scrum different from other Iterative models?

Scrum is not just an iterative model but it is an iterative model with incremental progress. Other Agile methodology include – KanBan, XP, Lean, FDD etc.

130. Mention what is the difference between Sprint and Iteration in Scrum?

Iteration: It is a terminology used to define single development cycle in general agile methods. It is a common term used in the iterative and Incremental development process. 

Sprint: It is used to define one development cycle or iterative step in a specialized agile method referred as Scrum. Sprint is scrum specific, and not all forms of iterations are Sprints.

131. How would you coordinate between multiple scrum teams?

It depends on the size and coupling between those teams, and there are various frameworks for it – 

• SAFe – Scaled Agile Framework 

• LeSS – Large Scale Scrum 

• SoS – Scrum of Scrum.