41. What is the structure of a good story?

The structure of a good story is as follows: 

1. Who are we building it for, and who are the users? - As a <type of user>

2. What are we building, and what is the intention? -I want <some goal or objective >

3. Why are we building it, and what value does it bring for the user.? - So that <benefit, value>

Well-formed stories will meet the criteria of Bill Wake's INVEST acronym:

1. Independent - Does your story have the potential to be stand-alone? 

2. Negotiable - Your story should have the scope to make adjustments. 

3. Valuable - There has to be some takeaway for users or customers. 

4. Estimable - The team should be able to use it for planning.

5. Small - Longer stories take more time to plan and implement. Keep your story short. 

6. Testable - Can you test the story? 

42. What is the role of a Scrum Master in a sprint retrospective? 

The scrum master in sprint retrospective inspects the progress of previous improvements. With the help of team discussion, new improvements are also inspected and adapted. Scrum Master plays the role of a facilitator for the team. 

43. How can Scrum Masters ensure timely delivery of action items? 

Regular scrum retrospective ensures timely delivery of action items. An effective retrospective makes sure that the team has identified the action items. Some organizations use a retrospective tracker to monitor action items. Here are the targeted categories: priority, ownership, status, description, identified on, and type. Working on the action items gives the team a boost that they are moving towards improvement and enhances the sense of ownership.

44. What exactly do you mean by Sprint in Scrum?

A Sprint is at the heart of Scrum. An incremental product is released every two weeks or every month. After the previous Sprint gets completed, a new Sprint begins. It breaks down large projects into smaller, more manageable chunks. It allows companies to produce high-quality work more frequently and quickly, making project management easy. Sprints have made them more adaptable to changes. Daily scrums, Sprint planning, sprint review, development work, and sprint retrospectives are part of a sprint.

• The Scrum Team as whole plans the work that gets accomplished during the Sprint planning phase.

• The Scrum Team values efforts and develops a plan for the following day during the Daily Scrum Meeting, a timed 15-minute session.

• At the end of each Sprint, a Sprint Review gets held to evaluate the increment and, if necessary, make changes to the Product Backlog.

• A Sprint Retrospective is held after the Sprint Review but before the subsequent Sprint Planning. The Scrum Team will evaluate its performance and develop a plan for implementing changes during the following Sprint during this meeting.

45. What does the concept of Confidence Vote mean in Scrum? Why is it vital?

The Confidence Vote is typically conducted during Program Increment (PI) Planning in SAFe (Scaled Agile Framework), not core Scrum, but it's used in scaled environments to assess how confident the team is in achieving their PI objectives.

After risk analysis and once all features and user stories are estimated, prioritized, and dependencies are clear, each team member votes - usually with a show of fingers (1–5) to express their confidence in delivering the planned work.

Why is it important?

• Promotes Transparency: It allows team members to honestly express doubts or concerns.

• Encourages Open Communication: Builds a culture where everyone’s voice matters.

• Boosts Morale: When people feel heard and valued, team cohesion improves.

• Risk Identification: Low confidence scores can reveal hidden risks or misalignment early on.

• Shared Ownership: The act of voting fosters commitment and accountability among team members.

If confidence is low, the team discusses concerns and re-plans if needed, ensuring better alignment and realistic commitments.

46. Is a daily meeting suggested for all teams, irrespective of their size or experience level? Explain.

During the daily meeting, a team can evaluate its progress in sticking to the sprint goal. To ensure that everyone is on the same page, all agile teams should meet frequently. Depending on their size and level of experience, they can conduct the meeting in different ways. 

• Small and Experienced - A small, experienced team can get together for a brief break or even an informal meeting.

• Small and Inexperienced - If the team is small and inexperienced, the Scrum Master should prefer going through a standup because the team needs to understand the progress. They may require assistance with technicalities or business functionality and must also understand the values, principles, and discipline.

• Large - Taking a relaxed attitude with huge teams may be troublesome, as formal meetings are required to provide advice and clarity.

• Distributed Teams - Because scattered teams are at a distance from each other, they can use the 'dial-in' feature to undertake meetings in an organized manner.

47. Can the Scrum team members participate in the product development process? If so, please explain how.

It is advantageous to involve the scrum team in the discovery phase stage of the product development lifecycle. Agile teams collaborate with stakeholders early in the development cycle to ensure that both parties are on the same page. 

• By identifying technical implementation issues early in the process, development teams can help modify specifications with the client.

• Working with the product owner, the team starts to share a common understanding of what needs to be ready. They can aid the product owner in identifying requirements that may have gone undetected.

• They share an understanding of what needs to be ready. It also helps teams maintain their dedication and confidence, encourages them to take ownership of their work, and, most importantly, boosts team spirit.

• To assist with this, the scrum master can begin involving teams in early product discussions while the requirements are still hazy. The product owner and the team can create the product backlog.

48. In Scrum, what do you mean by user stories? What benefits come from using them?

A user story is an informal, generic description of a software feature written from the end user's perspective. Its purpose is to explain how a software feature could benefit the customer. Putting people first is a critical element of agile software development, and a user story accomplishes this by putting end-users at the center of the discussion. These anecdotes use non-technical language to describe the development team and their efforts. After reading a user story, the team understands why they are developing, what they are building, and what value it adds.

The following are some of the benefits of using User Story:

• The primary benefit of User Story is the user-centric definition. It is because, in the end, the user will use the product in the relevant user scenarios. It creates a connection between end users and team members.

• The syntax of the User Story ensures that the user's desired goal, benefit, or value gets captured.

• Because the acceptance criteria get included in the user story, the Scrum Team will benefit from them.

• A user story can change at any time during the project's execution. If its scope becomes too large, it must be divided into smaller user stories. The conditions of the acceptance criterion can also be altered.

49. Why aren't the user stories' man-hours estimated?

Estimating clock-in-hours is one of the most popular methods for evaluating teamwork. Some significant disadvantages are:

• A few activities are difficult to estimate. Example – legacy work.

• If one team member provides the estimate, but another completes the task, the estimate is rendered useless.

• The developer's experience level determines the time it takes to complete a task.

• Teams frequently exaggerate the difficulties they may face and only consider the best-case scenario.

The following are some of the advantages of estimating user stories in points: 

• There is no correlation between the estimator's skills and experience, and story points are independent of the story's author. 

• Because story points measure relative sizes, and external forces cannot change their size, team members can estimate more accurately. 

• Story Points encourage collaboration by prioritizing team behavior over individual behavior. 

• It serves as a team-building activity because teams exchange, argue, constructively criticize, and have fun while playing poker cards to reach an understanding of estimations.

50. Differentiate between MVP and MMR

Minimum Viable Product (MVP) is a Lean Startup concept emphasizing the value of learning while developing a product. It allows the idea to be tested and understood by exposing target consumers and users to the initial version. To do so, one must first collect all relevant data and then learn from it. The MVP concept is to create a product, give it to consumers, and then watch how it gets used, perceived, and understood. It will also clearly understand your clients' or users' needs.

Successful products are gradually introduced into the market, with each "significant" deployment referred to as a release. An MMR (Minimum Marketable Release) is a product release with the fewest features possible that address your customers' current needs. MMRs reduce the time it takes to market between releases by condensing each release's coherent feature set to the smallest increment that provides new value to customers.

51. Name some other Agile frameworks.

There are other frameworks besides Scrum, such as Kanban, Test Driven Development, and Feature-Driven Development. Mention frameworks you have followed and provide scenarios.

52. When should you use Waterfall over Scrum?

Use waterfall if the requirements are simple, predictable, fully defined and understood, and will not change.

53. Would you recommend automated testing for your project?

Scrum encourages the use of automated performance or regression testing so that you can continuously deliver software as quickly as possible. Offer examples of any automated testing tools that your team may have used.

54. How long were your sprints?

An ideal sprint length is between one and four weeks, with a two-week sprint being the most widely used.

55. Is it okay if someone wants to change a requirement?

Yes. Agile encourages frequent feedback from customers and stakeholders so that the product can be improved. We need to be able to embrace change.

56. What type of metrics or reports have you used?

Sprint, release burn-down and burn-up charts are standard reports. Most companies also want to understand how many stories were committed versus completed per sprint and the number of defects identified post-release to production.

57. What is a burn-down chart?

A burn-down chart displays the amount of work a team has completed, such as hours during the sprint. Discuss how you have used these in the past.

58. How many Scrum teams have you managed at one time?

This is a popular question. Don’t offer that Scrum guidelines state only one Scrum Master per team as your answer! In this new role, you may be required to lead multiple teams. Notice the use of the word “managed” versus “led.”  Scrum Masters do not manage; they lead teams, so be sure to use this word in your response. Your interviewer is likely to be listening very closely!

59. What type of requirements did you use for your teams?

In Scrum, requirements are typically captured as user stories, using the standard format:

“As a [user], I want [functionality] so that [benefit].”

As a Scrum Master, I didn’t write the user stories myself, but I actively supported the Product Owner to ensure that:

• User stories were clearly written and followed INVEST principles (Independent, Negotiable, Valuable, Estimable, Small, Testable).

• Stories were prioritized in the Product Backlog.

• Requirements were refined and well understood by the Development Team before Sprint Planning.

• Stories met the Definition of Ready (DoR) before entering a Sprint.

My role involved facilitating backlog refinement sessions, promoting collaboration between the PO and the team, and ensuring that requirements were aligned with business goals and sprint capacity.

60. Describe a time when your Delivery team members didn’t seem to be getting along. How did you handle this?

In one of my previous teams, I noticed ongoing tension between two developers. They had different working styles and often disagreed during sprint planning and code reviews, which started affecting team morale and productivity.

How I addressed it:

• Private One-on-Ones:

 I first met with each person individually to understand their perspective without judgment. Both were passionate about delivering quality but had different approaches.

• Facilitated a Safe Conversation:

 I then held a neutral, private conversation between them, where I facilitated active listening and ensured both could express their viewpoints. I reminded them of our team values - especially respect and openness and encouraged them to focus on shared goals.

• Refocused on the Common Objective:

 During the next sprint planning, I emphasized the sprint goal and how collaboration impacts the team's ability to deliver value. I also introduced a short team-building activity during our Friday retrospective to rebuild trust and lighten the mood.

• Clarified Roles and Expectations:

 Some of the conflict stemmed from unclear ownership. I worked with the Product Owner and team to clarify story assignments and decision boundaries, which helped reduce friction.

Outcome:

Over the next few sprints, communication between the two improved significantly. They began pairing on tasks voluntarily and even contributed ideas to improve our code review process. The team dynamic became more positive, and our sprint velocity stabilized.