Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project

Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario, MoSCoW prioritization becomes essential to ensure the successful completion of the project. 

Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes.

What is the MoSCoW prioritization technique? 

The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for Must have, Should have, Could have, and Won’t have, each denoting a level of priority.

Here is the breakdown of the MoSCoW method: 

• Must have: These are critical requirements that the project cannot be completed without them. If these are not fulfilled, the project is considered a failure.
• Should have: These are important but not critical features of a project, and these are high-priority items that are not as time-sensitive as the Must-haves.
• Could have: These are desirable features that do not affect the overall project’s success. Therefore, they can be included if time and resources permit.
• Won’t have: These features are the lowest priority or are not necessary for the current delivery cycle. They are agreed upon and recognized but are dropped for the project’s current timeline.

The method’s roots trace back to the Dynamic Systems Development Method (DSDM), a framework used in agile project management. Its simplicity and effectiveness have made it popular across various industries, helping teams prioritize their tasks more effectively.

Why should you use the MoSCoW prioritization method? 

Based on its simplicity and clarity, MoSCoW makes it easy for all stakeholders to understand the project priorities. Besides, this method is also highly adaptable and can be applied across different types of projects and industries.

Moreover, it plays a crucial role in managing stakeholder expectations by clearly defining the project’s needs and wants. It provides a shared understanding of what’s crucial for the project’s success and what can be set aside if needed.

Compared to other prioritization methods, MoSCoW focuses on both inclusion (Must, Should, Could) and exclusion (Won’t). As a result, it offers a distinct advantage in managing stakeholder expectations and scope.

Benefits of using MoSCoW prioritization

If you're still skeptical about applying the MoSCoW method to your project, then why not take a look at these benefits? Surely, they will encourage you to have second thoughts. 

1. Provide clear prioritization

This prioritization technique provides a clear and easy-to-understand framework for prioritizing project requirements. By dividing requirements into each value of MoSCoW, teams can easily distinguish between what is necessary, what is important, and what can be postponed or removed from the current iteration or cycle.

2. Simplify the decision-making process

By categorizing tasks based on their importance and urgency, MoSCoW helps streamline decision-making processes. As a result, it empowers teams to focus on what’s crucial for the project’s success, thereby reducing the time spent on less critical tasks.

3. Enhance communication

The MoSCoW prioritization method enhances communication among project stakeholders. Additionally, it provides a shared vocabulary that all project team members, sponsors, and stakeholders can understand. 

Therefore, this shared understanding helps align everyone’s expectations, minimizing potential conflicts or misunderstandings.

4. Improve stakeholder management

This method offers an effective way to manage stakeholder expectations. By identifying and agreeing on the values of MoSCoW, stakeholders have a clear understanding of what to expect from the project.

5. Provide great project flexibility 

The MoSCoW method encourages flexibility by allowing requirements to move between categories as the project evolves and new information becomes available. As a result, this makes it particularly useful for agile development methodologies where flexibility and adaptation are key.

6. Allocate resources effectively

By clearly defining the priorities, MoSCoW plays a role in the effective allocation of resources. Teams can assign resources and schedule time based on the tasks’ priority level, ensuring the most critical tasks are completed first. 

7. Offer risk management 

MoSCoW prioritization helps mitigate risks by focusing on the completion of “Must-have” tasks. These are the most critical to the project, and by ensuring they are completed first, teams can prevent the project from failing.

How to implement MoSCoW in your project

With such benefits, you will undoubtedly want to implement this prioritization method in your project. 

Here is the step-by-step guide on how to do it: 

1. Begin by listing all project requirements.
2. Initiate discussions with your stakeholders to categorize each requirement into the Must Have, Should Have, Could Have, and Won’t Have sections.
3. Next, you should facilitate negotiations among stakeholders when there is disagreement on the categorization of certain requirements.
4. Document the categorization and make it available to all stakeholders.
5. Review and adjust priorities throughout the project as necessary.

Mistakes to avoid while using MoSCoW

While the MoSCoW method is simple, certain common mistakes can affect its effectiveness and your project as a whole. 

For example, categorizing too many features as “Must have” can lead to confusion and delay. Therefore, it is essential to maintain a realistic and balanced distribution of requirements across the categories.

Another common misunderstanding is the belief that “Won’t have” features are not necessary.

These are the features that could bring additional value to the project but are not feasible in the current delivery cycle due to time or resource constraints. As a result, you can easily sleep on these potential features without knowing that they could be the turning point of your project. 

To avoid such mistakes, you should remember to look back and review all criteria. This practice will help you avoid overrating specific features while underestimating others. 

Final thoughts on the MoSCoW prioritization

The MoSCoW prioritization technique provides a straightforward and effective way to manage project requirements effectively. By providing clear categorization, it simplifies decision-making, facilitates communication, and helps manage stakeholder expectations. 

Whether you’re in software development, event management, or any industry involving project management, MoSCoW can prove to be a valuable tool.

 

1. What is the difference between agile and scrum?

Hiring managers may ask this question to understand a candidate's clarity on agile project management software. Answer this question by discussing the key differences and a few similarities between agile and scrum. Also, explain your work experience with these methodologies to demonstrate your comprehensive insight into agile.

Example: Agile is a project management and software development methodology that enables teams to deliver work efficiently. Its flexible approach allows cross-functional teams to associate and stay on track with a project using tracking tools.

Scrum methodology is an agile framework that facilitates team collaboration for software development and testing. You can split each project in the scrum into small workable builds called sprints. In each sprint, team members take up a specific project function and complete it within the sprint timeline of two to three weeks,

Scrum and agile follow collaborative iterations and incremental builds for projects. In my experience, Scrum is rigid and produces quick results, while agile is flexible and suitable for small teams with creative and experimental project approaches.

 

2. What process do you follow to plan an agile project?

This question aids recruiters in identifying your work style with agile. You can explain your agile project planning process one step at a time.  Alternatively, you could describe a standard agile project plan and discuss how you remain efficient in the project with detailed planning.

Example: I follow a systematic method and involve concerned stakeholders while planning an agile project. The project starts with developing the product vision and discussing it with my team to finalise the product vision statement. The next step is to set project goals through a product road map and identify a strategy to accomplish those goals. Once the plan is ready, my team creates sprint plans and conducts daily scrums to meet sprint deadlines.

Afterwards, I review the sprints and plan a sprint retrospective meeting with all the teams to discuss challenges and improvement areas. I focus on involving all the team members in an engaging discussion for successful project execution.

 

3. What is the work breakdown structure?

Interviewers might want agile project managers who can handle extensive and complex projects. The work breakdown structure assists managers in finishing projects within target dates while adhering to the client's specifications. You can describe the work breakdown structure, features and importance through your response.

Example: Work breakdown is the hierarchical arrangement of tasks by breaking them into sections and tracking them. This technique aims to create a common understanding of the project scope. Each section is descriptive and simplifies complex tasks into small sub-tasks, which prevents delays and facilitates careful monitoring. There are four levels in the work breakdown structure. They are project deliverables, work accounts, work packages and activities, and they support the cautious organisation of each task component.

 

4. What factors are responsible for impediments in scrum during the project planning process?

The scrum team may face challenges throughout the project, and hiring managers typically want to understand how project managers identify these issues and resolve them. Identify challenges in the scrum process and suggest some solutions to them. Alternatively, you could give examples from your work experience in your answer.

Example: A few factors responsible for challenges in the scrum process are a lack of resources or team members, conflicts between departments, operational issues, a lack of cooperation between stakeholders and technical glitches within the software. As a project manager, I try to satisfy customer demands by delivering products on time and according to their requirements. Effective communication between all collaborators helps resolve conflict issues. It is also important to communicate the team's requirements to the upper management to resolve operational and technical barriers in the project execution process.

 

5. What do you understand by scrum of scrums, and how is it different from a daily scrum? Could you explain with an example?

As a project manager, you might execute sophisticated projects by connecting with multiple teams. Interviewers may try to learn about your leadership and management skills through this question. It is advisable to answer by detailing the concept of scrum of scrums. Including an example from your experience can give the recruiters more insight into your scrum knowledge.

Example: Scrum of Scrums is an agile technique that allows for connecting multiple teams virtually and reducing the number of communication lines. The manager divides the teams into smaller groups that connect with each other for the assignment and delivery of sprints. This helps all the team members work towards a common goal and deliver quality projects. A daily scrum is a stand-up meeting where a team plans the work for the day and tracks a project's development.

I feel Scrum of Scrums is important for delivering customer value through integrated product development, while daily scrum is necessary to track the progress of team members and avoid delays.

 

6. How does an agile team maintain project requirements?

Interviewers may test your knowledge and understanding of the agile team. You can showcase how you assist or plan to assist your team in maintaining project requirements at the different stages of product development. Approaching your answer this way might help you perform well in the interview stage.

Example: An agile team uses a product backlog to maintain project requirements. An agile team is a group of people working on a project and having all the resources to produce a quality product. The three important roles in an agile team are the product owner, scrum master and development team. The product owner prioritises customer requirements, and the scrum master looks after the development team's requirements and facilitates daily meetings. The project manager provides resources and personnel to assist the agile team in maintaining project requirements.

 

Capacity Planning in Scrum

Tips and Techniques

Capacity planning is something that I take very seriously as a Scrum Master. When working with large-scale projects using the Scaled Agile Framework (SAFe), I have found that it becomes even more important to effectively manage program-level capacity planning and align team capacity with business goals.

As a Scrum Master, I understand that capacity planning involves estimating the team's available capacity during a Sprint, which is a time-boxed iteration typically lasting two to four weeks. To effectively calculate capacity planning in a Scrum team, I consider factors such as team size, availability, skill set, and work capacity.

To calculate capacity planning, I use the SAFe Framework's set of tools and techniques, including the Program Increment (PI) Planning process, which aligns team capacity with business goals and objectives, and the Capacity Allocation Matrix (CAM), which manages team capacity across multiple teams.

Firstly, I define the team's capacity for the Sprint, based on the number of team members and the number of working days in the Sprint. I then account for non-working time, such as holidays or planned vacations, by subtracting this time from the team's available capacity to get the adjusted capacity. I also take into consideration each team member's availability during the Sprint.

Once I have determined the team's available capacity, I allocate tasks based on the amount of time each task is expected to take. It is important to distribute tasks evenly across team members and avoid overloading any one team member.

Capacity planning is a critical part of Scrum project management, and it becomes even more important when using the Scaled Agile Framework (SAFe) to manage large-scale projects. The SAFe Framework provides a set of tools and techniques for managing program-level capacity planning and aligning team capacity with business goals.

In Scrum, the capacity of a team is the amount of work that the team can accomplish during a Sprint, which is a time-boxed iteration typically lasting two to four weeks. Capacity planning involves estimating the team's available capacity during the Sprint and allocating tasks to team members based on their available time.

To effectively calculate capacity planning in a Scrum team, it's important to consider factors such as team size, availability, skill set, and work capacity. Here are some tips on how to calculate capacity planning in a Scrum team

• Define team capacity: Start by defining the team's capacity for the Sprint, which is typically based on the number of team members and the number of working days in the Sprint. For example, if a team has six members and the Sprint is two weeks long, the team's available capacity would be 6 x 10 (assuming a five-day workweek) = 60 hours.
• Account for non-working time: Account for non-working time such as holidays or planned vacations by subtractin g this time from the team's available capacity to get the adjusted capacity. For example, if the team has one member who will be on vacation for one week during the Sprint, their available capacity would be reduced to 5 x 8 = 40 hours.
• Consider team member availability: Take into consideration each team member's availability during the Sprint. For example, if a team member is only available for half of the Sprint, their capacity would be reduced by 50%.
• Allocate tasks based on capacity: Once you have determined the team's available capacity, allocate tasks based on the amount of time each task is expected to take. Make sure to distribute tasks evenly across team members and avoid overloading any one team member.

As a Scrum Master, it is important to understand the difference between capacity and velocity in a Scrum team. Capacity is the amount of work that a team can accomplish during a Sprint, whereas velocity is a measurement of the team's output over multiple Sprints.

Velocity is calculated by adding up the number of Story Points that the team completes during each Sprint. Story Points are a unit of measure used to estimate the relative size of a user story, feature, or other piece of work.

In conclusion, capacity planning is a crucial part of Scrum project management, and the SAFe Framework provides a range of tools and techniques to help manage program-level capacity planning. By using these tools and techniques, Scrum teams can effectively allocate tasks based on available capacity and ensure that they meet their business goals and objectives. As a Scrum Master, I find that SAFe's approach to capacity planning is both effective and efficient in ensuring that Scrum teams can deliver high-quality work consistently.

 

 

=== More questions & Answers  ===

1 ) Greenfield project Vs brownfield project

Ans : The same goes for IT projects – a greenfield project is a brand new one, developed from scratch, and not based on any existing systems, code or infrastructure, unlike a brownfield one, which is built upon already existing projects, code or other resources.

 

2) Waterfall Model Vs Agile :

Ans : Read some 9 project techniques : 9 Project Management Types For A Project Manager | Indeed.com India

 

Agile Methodology

• Approach: Frequent stakeholder interaction
• Flexibility: High
• Requires: Team initiative and short-term deadlines

Agile methodology was developed as a response to Waterfall’s more rigid structure. As a result, it’s a much more fluid form of project management. A software development project can take years to complete, and technology can change significantly during that time. Agile was developed as a flexible method that welcomes incorporating changes of direction even late in the process, as well as accounting for stakeholders’ feedback throughout the process.

In Agile, the team will work on phases of the project concurrently, often with short-term deadlines. Additionally, the team, rather than a project manager, drives the project’s direction. This can empower the team to be motivated and more productive, but also requires a more self-directed team.

Waterfall Methodology

• Approach: Hands-off; goals and outcome established from the beginning
• Flexibility: Low
• Requires: Completing deliverables to progress to the next phase

Waterfall methodology is a linear form of project management ideal for projects where the end result is clearly established from the beginning of the project. The expectations for the project and the deliverables of each stage are clear and are required in order to progress to the next phase.

 

3)  Benefits of Agile :

Ans :

The benefits of Agile

The benefits of Agile project management will vary from case to case, as different teams implement best practices their own way. However, it is generally understood that Agile offers the following core benefits:

1. Satisfied customers

By involving customers in the development process, Agile teams keep them in the loop and show that they value their opinion. Stakeholders want to be engaged throughout the project life cycle so they can offer feedback and ensure that the final product will be suited to their needs. These tailor-made deliverables will likely improve the overall user experience and boost customer retention.

2. Improved quality 

Agile methodologies use an iterative approach to project management, meaning processes are improved upon each time an interval is repeated. This consistent focus on improvement and quality control is one of the core principles of Agile, and it helps to create superior products.

3. Adaptability

The central theme of Agile is flexibility. Agile teams are responsive to change, even at the last minute, and can adapt to it without much disruption. Project deliverables are not set in stone, so teams can easily reassess their plans and adjust their priorities to align with updated goals. Being adaptable means teams can deliver consistently and manage clients’ changing requirements effectively.

4. Predictability 

Agile teams work in short time periods, sometimes referred to as sprints. These fixed durations (e.g., two weeks) make it easier for project managers to measure team performance and assign resources accordingly. It is also easier to predict costs for shorter time periods than for a long-term project, simplifying the estimation process. 

5. Reduced risk

Developers regularly assess progress during sprints, meaning they have better visibility into the project and can spot potential obstacles quickly. These minor issues can be tackled before they escalate, creating an effective risk mitigation process and giving the project a greater chance of success.

6. Better communication

Agile teams prioritize face-to-face communication and continuous interaction. They will usually conduct daily meetings to ensure everyone is on the same page and working towards the same objectives. By regularly communicating with each other, they eliminate potential confusion to successfully achieve their objectives. 

The advantages of Agile

The Agile approach is often considered the superior option when compared to opposing project management methodologies. Let’s take a look at some examples:

Agile vs. Waterfall

Waterfall is perhaps the most well-known traditional methodology in project management. It follows a structured, linear process, where each task must be completed before moving on to the next one. Though this methodology might be perfectly suitable for a long-term project (e.g., construction), it would not work in a fast-paced software development environment, where clients regularly change their minds and insist on new deliverables.

Take US media giant NPR as an example. The organization made the switch from Waterfall to Agile to avoid “undesirable consequences,” such as a situation where the final goals differed completely from what was outlined at the beginning of the project. As they weren’t even sure what project they wanted to build, the Waterfall method of creating a fully defined plan simply did not fit. This is why they opted for Agile to allow more flexibility in their process.

Agile vs. Lean

The Lean methodology takes a streamlined approach and aims to eliminate unnecessary waste. There are clear similarities between Agile and Lean, including a focus on customer satisfaction and fast delivery. However, it could be argued that Agile has an advantage in terms of structure.

As previously stated, Agile is far more flexible than its traditional counterparts, but it still offers a desirable sense of structured organization, as seen with its clearly defined roles, regular meetings, and systematic reviews. This level of discipline makes Agile easier to implement than Lean, which is more focused on the cultural thinking within an organization. The Lean theory is not as tangible as Agile’s versatile structure and may be more challenging to put into practice.

Agile vs. PRINCE2

PRINCE2 (Projects In Controlled Environments) is a methodology characterized by product-based planning. It uses a structured project board for high-level activities while a project manager looks after day-to-day operations. PRINCE2 is useful for higher management, but it lacks the emphasis on delivery that Agile has.

Agile does not follow a predictive, plan-based method as PRINCE2 does. Instead, Agile teams focus on delivering working software to customers at the end of every sprint and use feedback to inform their development process. This short-term approach makes Agile far more adaptable to consumer needs.

 

4) Explain any 4 agile principles and Agile values with real time use examples or how you relate to work/implement in the project

Ans : The Four Values of The Agile Manifesto

The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development. Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.

1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.

2. Working Software Over Comprehensive Documentation
Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.
The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out the details of a delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.

4. Responding to Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.

With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.

The Twelve Agile Manifesto Principles

The Twelve Principles are the guiding principles for the methodologies that are included under the title “The Agile Movement.” They describe a culture in which change is welcome, and the customer is the focus of the work. They also demonstrate the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs.

 

#1 Customer Satisfaction is the highest priority

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

In short, this means we should release early and often to benefit our customers. Iteration and feedback are at the core of what it means to be Agile, referred to here as “early and continuous delivery.” Early delivery is important because the longer it takes a customer to see the direction of a project the more likely it is to diverge from their expectations and requirements. Meanwhile, continuous (and consistent) delivery helps the project maintain a rhythm while allowing for iterative review along the way. As we’ll see in the other agile principles, sustainable development is key to being Agile!

Another core feature of Agile is the ability to adapt to change which is shown here by describing this method of delivery as “our highest priority.” Despite being written like 12 commandments, Agile is not set in stone, so instead of saying “Thou shalt deliver continuously,” this principle urges you to prioritize this wherever possible. Phrasing and semantics aside, this agile principle also highlights that we should aim to “satisfy the customer” with “valuable software” by proactively meeting their needs, which goes without saying but is all the more important to not lose sight of.

#2 Welcome changing requirements, even late in development

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

This second principle means that we should be willing to make changes to stay competitive, and it outlines a common fear to address when becoming Agile. Chances are high that when someone studies Agile they’ll wince when they get to the part about “changing requirements,” but it’s absolutely necessary and one of Agile’s core strengths. Adapting requirements as more information is gathered ultimately leads to the production of an effective and competitive product which is important in the long term. 

As with the first principle, saying “Welcome” doesn’t dictate the action you should take, just that you should allow and assess changing requirements at every stage of development instead of dismissing it outright. To address concerns, this agile principle highlights that allowing for change gives the customer a competitive advantage which is necessary for a successful business and by extension the software team it hires. Being Agile means providing this benefit to your customer, so if you’re queasy about late development requirements changes, ask yourself if dismissing the change will affect your customer’s competitive advantage, and then recommend what is best for them.

#3 Deliver working software frequently

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

The third Agile principle is likely known even by fringe Agile users, and it boils down to trying to release on a shorter frequency. If you’re familiar with what Scrum is, this would refer to “sprints” where work is planned for one or two weeks after which working code is presented to the team. This shorter delivery time allows teams to get earlier engagement from clients and stakeholders, which Agile uses to adapt to changing requirements (callback to principle 2!). Like the other suggestive agile principles, this one allows for the idea of month-long time periods but puts the priority on smaller intervals when possible.

The operative word in this principle is “frequently,” which implies both consistency and regularity. In principle 1 we talk about delivery being continuous because it needs to be sustainable, and here we add on that it needs to be consistent and have an end time – like a pay period. Agility is more about moving correctly than moving fast, so stepping through your project with short, even, and calculated steps is key to being Agile. Even if your project doesn’t easily lend itself to a sprint structure, see if you can still have some shorter, more frequent deliveries.

#4 Business people and developers must work together daily

“Business people and developers must work together daily throughout the project.”

Number four can be a major hurdle for becoming Agile, but in essence, it asks that you include both the business and tech groups in daily work. In this case, daily work is considered anything your team does on most days like status updates and the internal discussions that happen between scheduled meetings. By looping in both sides throughout the process – like when making a notable on-the-spot design decision – the communication channels will be open so everyone is on the same page and immediate feedback can be given if necessary. The added perspectives help to make sure that important details receive adequate attention before they get baked into a part of the project.

A common rebuttal is that doing this will cost more time, but this should ideally optimize those long checkpoint meetings by dedicating less time to getting up-to-date and more time towards planning the next phase. I am also confident that anyone reading this article has recognized disconnects between their tech and business teams in the past, it’s not only common, but it gets worse when projects get faster or more complex. Recognizing gaps early and often is a cornerstone of being Agile, and with how large gaps can grow between business and tech teams it’s imperative to stay on top of things.

#5 Build projects around motivated individuals

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Agile Principle 5 focuses on giving passionate teams room to work. It’s easy for a team to lose motivation – we’ve all been there – but building that passion is great for the project and the people. Using motivated individuals to build a product and giving them the tools to really shine is a great way to turn a project into a work of art as opposed to just another task – this is where principle 5 comes in.

You can start by finding ways to plan the project with the team, like adding some leeway to the structure so a team member can show their ideas or section out work based on individual interests. As the project starts to build momentum, follow up with your team to see what they need in order to be successful. This is what most teams do when trying to build motivation, and the closer this is to the project-building step the easier it is to do. Notice how this agile principle doesn’t mention speed or efficiency? This is because being Agile is also about doing things well – why make software quickly if it’s not good?

If you are having difficulty finding the right people, you can always hire on-demand talent; professionals who will be uniquely suited to and interested in your project! 

#6 Face-to-face conversations for conveying information

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Truly a principle not written in 2020, number 6 tells us that information is easiest to convey with personal communication. Email, texting, and other messaging platforms all have their own benefits, but it is usually at the expense of overall effectiveness for relaying information. Effective and efficient conversation comes from hearing someone’s voice and seeing each other’s expressions. 

This of course relates to face-to-face communication, but in today’s world companies have noticed (or have been forced to notice) that this can be translated to video calls for remote work. The expressions are there, you can be heard, and you can even record the conversation giving it every advantage for effective communication – unless of course you think smelling someone is important. Communicating clearly is important to Agile and non-Agile teams alike, but given Agile’s frequent engagements this principle warrants special consideration.

#7 Tracking outputs instead of done tasks

“Working software is the primary measure of progress.”

Agile Principle 7 – my personal favorite – is the often incorrectly done task of measuring software in working features. You may have heard of the Ninety-Ninety rule that says when a software task is ninety percent done, the final ten percent takes just as much time to complete as the previous ninety. This makes light of the common pitfall of measuring a task by what’s been developed so far without accounting for testing, things breaking, revisions, refactoring, and all the other reasons we’ve attached to timeline extensions.

By measuring the progress of what has been completed, you plant your feet and say “this feature works, and the client accepts it” indicating that your team is now ready to focus on something else. As you can guess, working software doesn’t just refer to the final product, it also refers to the deliverables in principles 1 and 3 in which every iteration should have a working feature to show the client. Tracking outputs is a key way to validate that your Agile process is functioning effectively.

#8 Agile processes promote sustainable development

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

The bane of any crunch-time enthusiast, principle 8 specifies that an Agile process can be done indefinitely – without the development team combusting. Having to regularly put in extra time to meet deadlines can quickly wear down a team. This kind of pace is sporadic and unsustainable and by definition not Agile. This does not mean you have to work slowly, it just means you have to work at a pace that’s sustainable – be it slow but deliberate refactors, or fast but calculated deliveries.

Though a senior project manager would never think of a project’s timeline as indefinite, it’s almost guaranteed that there will be post-production work that can build up over time. Chances are that if you crunched to deliver a project, you’ll be under pressure to address the issues afterwards to stay in line with that precedent of speedy delivery. Specific processes aside, if you want to be Agile you need to organize your process so that it can maintain its pace. If you don’t think your team can follow your processes consistently, changes should be made.

#9 Technical excellence and good design

“Continuous attention to technical excellence and good design enhances agility.”

The 9th principle is hard to commit to for any corner-cutters as it specifies that agility is improved by doing best-practice work. During a software project, it’s enticing to save time by doing something less-than-excellent, despite the fact that it could save time in the future if good design choices were made now. Making your attention to excellence continuous (there’s that word again) improves how you handle complexity in the project, which as we’ve mentioned, is part and parcel with Agile. Committing to good design makes the code require less upkeep and reduces the technical debt which can slow down projects later on. Part of being Agile is making it easier to move fluidly through the entire lifespan of a project, so if doing something now would make development easier going forward, consider doing it.

#10 Simplicity is essential

“Simplicity – the art of maximizing the amount of work not done – is essential.”

Agile Principle 10, the most likely to be on a LinkedIn post, talks about simplifying the scope by identifying what we don’t need to do. This is about working smart, not hard. By recognizing what adds value and what doesn’t, you can choose how to allocate your resources to best serve your project. Aim to identify what is and isn’t necessary, and use that to focus your efforts. Early on in a project, this often takes the shape of a Minimum Viable Product (MVP) – working software that meets the primary use cases of its audience while leaving out the bells and whistles.

This is another hugely important agile principle and one that doesn’t leave any ambiguity. Too often projects get bogged down by doing more than is necessary while important features are neglected; instead we should look at the work that doesn’t need to be done and maximize it. Being Agile never really means coding faster, but you get your speed boost by coding more efficiently.

#11 Self-organized teams

“The best architectures, requirements, and designs emerge from self-organizing teams.”

In addition to being passionate, principle 10 asks that your team is also self-organizing for the best product. A self-organizing team is a group that can plan, estimate, and complete work by themselves while proactively engaging stakeholders as needed. This is a tenant that could fill an entire article, so for now, let’s focus on the heart of the principle.

Letting a team organize itself can be a hard sell for management but it’s all about saving time over the duration of the project. Managing a team is a lot of work and usually requires sizable meetings to give direction and understanding, but a self-organizing team is simply given a high-level primer and then allowed to run from there. Add this together with Agile’s iterative nature and regular engagements and control comes back because even though the team is managing themselves, you get to jump in more often to redirect the project as needed. This principle is hard to fully commit to right away as it involves trust, but if you want to be Agile you’ll want to give your team some leeway to organize themselves, even if it’s only a little bit to start.

#12 Ensure teams inspect their process and adapt frequently

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Finally, at principle 12, we talk about the heart of Agile principles: ensuring teams inspect their process and adapt frequently. None of this will be executed perfectly on the first try, even if you get a professional to implement Agile principles for every team they’ll adapt it to your unique team and business using reviews and retrospectives. Throughout this article we’ve called back to previous principles, but this one can be referenced in every instance of Agile because no matter what you’re implementing, you should make time to inspect what you’re doing and adjust how it works until you’re comfortable.

5) Difference between Coaching, Mentoring and Training approach ?

Ans : Coaching is focused on improving performance, skills, and mindset, while mentoring is more about sharing knowledge, experience, and wisdom.

6) knowledge about Jira Tool

Ans : Jira is the #1 agile project management tool used by teams to plan, track, release and support world-class software with confidence. It is the single source of truth for your entire development lifecycle, empowering autonomous teams with the context to move quickly while staying connected to the greater business goal.

Welcome to Jira | Atlassian

 

7) why 2 weeks sprint ?

Ans : Two week sprints mean we catch any potential issues faster. Getting feedback at the end of every sprint helps us shape the project moving forward, and ensures that everyone is on the same page, and working toward the same goal.

In shorter sprints, teams are more focused. It happens because they are more likely to remember what each work item entails. And they can keep track of the status of each working item. So teams working in a sprint of short length will deliver more quality and this gives them more satisfaction.

Two week Sprint Calendar

• Don't start or end on Mondays or Fridays. ...
• First day of the sprint is sprint planning.
• Last day of the sprint is retro and demo.
• Work in backlog refinement as often as your team currently needs it. ...
• And then stand up is every morning for 15 minutes.

 

1-week sprint: For teams that are used to fast-paced work and agile environment and are able to produce product updates and new features in a week. 

2-week sprint: An optimal speed for every team that wants to work in sprints and increase velocity. 

3-week sprint: For teams that aren't used to fast-paced structured work.

4-week-long sprints are for software teams that are still "children" at practicing scrum.

 

8) What are the scrum values and how you implement in the work ?

Ans : The five Scrum values are commitment, focus, openness, respect, and courage. In the Scrum framework, these values serve as a guide for individual and team behavior, intending to boost collaboration and increase the odds of project success.

1. Courage

“Scrum team members have the courage to do the right thing and work on tough problems.”

Scrum values the courage of each individual contributor to the team. While we may not always think of courage in the context of an office job, there are certain circumstances that require some bravery.

For example, it takes courage to point out a mistake even when correcting it will cost your team some time. It takes even more courage if that mistake was made by a superior. Having courage also means tackling difficult challenges head-on rather than procrastinating or passing them off to a colleague.

2. Focus

“Everyone focuses on the work of the Sprint and the goals of the Scrum Team.”

In Scrum, a Sprint is a block of time (no more than four weeks long) in which the team concentrates on a specific set of objectives. On a Scrum Team, focus means that during a Sprint, each individual sets aside pet projects and resists the temptation to work ahead or go back to touch up other tasks.

Every team member must concentrate on the activities included in the Sprint plan in order to support the goals of the team.

3. Commitment

“People personally commit to achieving the goals of the Scrum Team.”

Scrum relies on the personal commitment of each team member to complete the project. It assumes a fairly flat authority structure and does not expect managers to convince or coerce team members into completing tasks.

Instead, Scrum leads to success on the virtue of each individual’s commitment to the good of the project.

4. Respect

“Scrum Team members respect each other to be capable, independent people.”

Scrum generally consists of collaborative and self-organizing teams, but each member is independent in the sense that no one is constantly checking his or her work. It is assumed that each individual is capable of doing her job without constant oversight or “checking in” by a manager or coworker.

This also means encouraging and expecting people to ask for help when they need it, trusting that every team member will be ready to help since each is committed to the project’s success.

5. Openness

“The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.”

Nearly every project comes with challenges. Scrum values openness and honestly communicating to all stakeholders without fear. This means telling a team member honestly if something needs to be re-done and receiving that kind of communication graciously, trusting that everyone is working toward the same goals.

This value of openness also means that project stakeholders are expected to communicate promptly and honestly, if, for example, changes in timeline, resources, or product needs occur.

How to apply scrum values in day to day life

Courage, focus, commitment, respect, and openness are excellent values for any workplace, even if you aren’t operating in the Scrum framework. But how do you implement values like these on your team?

Communicate the values. Discuss what you’ve learned about Scrum values with your team. You don’t even have to call it “Scrum” if you think that will be a hindrance. Just have a conversation with your team and get buy-in on implementing these five values.

Be the example. As the team lead or project manager, it’s unlikely your team will consistently practice these values if you aren’t.

• Demonstrate courage by taking on difficult tasks.
• Show focus by keeping to your schedule.
• Embody commitment by doing your work well and assuming your team is also.
• Respect your team members by trusting them to do their work independently.
• Model openness by admitting your mistakes and communicating both honestly and kindly about areas for improvement on the team.

 

9) what is the empirical process and give the example

Ans : Empirical processes are those that rely on data and observation to make decisions. In the world of software development, this means that teams use feedback from their users and stakeholders to constantly improve their products.

Examples of the Empirical Process in Action

All of the scrum events are opportunities for empiricism. With empiricism, we learn by doing to make better decisions. The scrum events provide opportunities to discuss what we've learned and to make those better decisions. Here are some ways empiricism appears in the scrum events:

Sprint review. The sprint review is a great example of transparency and inspection in action. In the sprint review, the scrum team shares their sprint outcomes for inspection by stakeholders and anyone else who has been invited to the review. 

While every team may run their review differently, there is the objective standard of the definition of done that can be brought into the review discussion.

Depending on the feedback gathered during the review, the team may adapt the product backlog or their plans for upcoming work. 

Sprint retrospective. In the sprint retrospective, the scrum team may discuss their collaboration, interactions, communication, processes, tools, and their definition of done. The goal is to identify problems and opportunities, wins and challenges, and then develop and choose action items to carry forward in their work. 

Daily scrum. Daily scrums are 15-minute daily events in which the developers embody transparency by discussing progress, work planned, and work stalled with the purpose of synchronizing their collaboration and efforts. All developers inspect progress and impediments and consider adaptations that might help the team achieve its sprint goal. 

Sprint planning. In the sprint planning event, the product owner can embody transparency by sharing their proposal for a goal for the sprint (the sprint goal is a stepping stone on the path to the product goal). The entire scrum team inspects this goal and the product backlog items in order to develop and adapt a backlog for the sprint.

Scrum's Empiricism Drives Transparency, Inspection, and Adaptation

Scrum is based on empiricism, which involves observing events and artifacts in the world to make forward-looking decisions. This approach benefits both employees and organizations through the opportunity to be more predictable, faster to market, to innovate, to delight customers, and to pivot in response to change.

 

10) why we are having daily stand-up Meeting?

Ans : The daily stand-up is a short, daily meeting to discuss progress and identify blockers. The reason it's called a “stand-up” is because if attendees participate while standing, the meeting should be kept short. For software teams, a stand-up is like a sports team's huddle.

 

11) What is retrospective?

Ans : An agile retrospective is an opportunity for agile development teams to reflect on past work together and identify ways to improve. Agile teams hold retrospective meetings after a time-boxed period of work is complete.

 

12) What are the Pillars of the empirical  process ?

Ans : The Three Empirical Pillars of Scrum 

The three empirical pillars in scrum are transparency, inspection, and adaptation. These three behaviours are what allow your scrum team and stakeholders to gain knowledge about what you're creating based on their ability to observe and provide feedback, and your ability to quickly pivot when needed. 

Empirical process control—a way of managing work based on experience and observation—provides the opportunity to examine "how" a product is created, which is just as important as "what" is being made.

Here's a closer look at the three empirical pillars that support empirical process control:

• Transparency means that the process and work must be visible to your scrum team and stakeholders. Everyone must be able to see the artifacts (product backlog, sprint backlog, and increments) in order to inspect them.
• Inspection means that team members and stakeholders examine the scrum artifacts and other outcomes. Successful inspection depends on transparency—if you can't observe, access, and experience all the essential artifacts, practices, working agreements, and more, then you can’t inspect them.
• Adaptation means making adjustments to the work, artifacts, or your plan based on the results of your inspection and the feedback you received. Inspection may reveal an opportunity to improve interactions and collaboration. It may reveal a needed change for the product backlog or the product goal. To adapt immediately, scrum teams need to be empowered and self-managing. 

 

13) how many scrum teams you have handled, on time  and team size

Ans : As a Scrum Master I have handled 2 teams at once.

1^st team size was 10 è

Developer – 6 : Front end – 2 and Backend -4

QA 2 , 1 SM, 1 PO

Java Full Stack è FE- Angular, BE - Java

2^nd team was size was 9 è

Developer – 5 : Front end – 3 and Backend -2

QA 2 , 1 SM, 1 PO

.NET Full Stack è FE- ASP.Net, BE – VB.Net

 

14) what are the various prioritization techniques? Explain one which you are using  in the project ?

Ans :

·        MoSCoW prioritization 

·        Kano model 

·        Relative weighting method

·        Opportunity Scoring

·        Stack Ranking

·        Priority Poker

·        Cost of Delay

·        100 Dollar Test

MoSCoW Prioritization in Agile: In the Dynamic systems development method (DSDM)

the priorities are expressed as per the MoSCoW model:

·        Must– The must requirements is given the topmost priority

·        Should– Next priority is given to the requirements that are highly desirable, though not mandatory

·        Could– The next priority is given to the requirement that is nice to have

·        Won't– And the final consideration is given to the requirements which will not work in the process at that point of time.

The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

 

15) who can cancel the sprint ?

Ans : Only the Product Owner has the authority to cancel the Sprint.

 

16) in which scenario PO will cancel the sprint ?

Ans : A Sprint can be cancelled before the Sprint time-box is over. A Sprint would be cancelled if the Sprint Goal becomes no longer produced or used; out of date. This might occur if the company changes direction or if market or technology conditions change.

 

17) After the sprint cancellation, tasks will go ?

Ans : Product backlog

When Product Owner cancel Sprint, all the work done until that moment is evaluated and remaining work items are pushed to product backlog for further analysis.

 

18) PO should be available through out the sprint ?

Ans : Yes .

·       The Product Owner plays a crucial role in Agile projects, and their absence during a sprint can have negative impacts on the team’s productivity and progress.

·       Planned or unplanned absence of the Product Owner should be handled with suitable alternatives, such as appointing a proxy Product Owner or empowering the development team to make certain decisions.

·       Scenarios like personal emergencies or lack of motivation/commitment can lead to a Product Owner’s unavailability, and it is important to address these issues and find suitable solutions to ensure project success.

 

19) When scrum fails ?

Ans :

1. Lack of Understanding of The Scrum Framework Among Team Members

It is very important to have a good understanding of the Agile Scrum principles, strategies, and approaches. It is equally important that all team members have a common understanding of the Scrum framework, as well as the Scrum roles in the team. The team should know the distinct roles and responsibilities that the Product Owner, Scrum Master, and developers should play.

2. Scrum as A Process Rather Than A Framework

Some experienced developers that work with other software development methodologies for a long time tend to see Scrum as just another process, but it is much more that. It is a framework for you to define your development process in order to match your requirement within a given set of guidelines. It is about fine-tuning and making continuous adjustments to the process based on empirical data from the short development and release cycles.

3. Scrum for All Types of Projects

Scrum has its own values and benefits, but only if applied for the correct project. A Scrum process will not provide the expected results if it is forced to fit a project, or vice versa.

Scrum encourages autonomy and flexibility in the team to find their way. This works extremely well when team members have shared skills and experience. So, if your project involves an abundance of research and consists of developers in specialized areas of knowledge and expertise, you need to think twice before adopting Scrum.

4. Scrum Purely as A Status Monitoring Tool

Scrum promotes evidence-based management practices, so there is no requirement to constantly monitor the individual or the team. Nevertheless, there are many tracking metrics such as burndown and velocity which are available for management to see the progress of the project.

5. Micromanagement of Scrum Teams

 

20) If PO is not available , then what will the impact on the ongoing sprint?

Ans : It’s imperative that they are present and participating for effective communication, decisions and task-prioritization.

·       Without them around, teams get stuck waiting for clarifications and approvals.

·       Without their guidance, there is a chance of wrong interpretation of requirements, resulting in wasted effort.

·       Also, stakeholders may not have anyone to talk to regarding their queries or project progress.

Furthermore, the development team may feel unsupported and unmotivated without the Product Owner’s presence. This can affect their productivity and morale.

What is most likely to happen if the Product Owner is not available during a sprint - Talent Cove

 

21) Can PO do the SM work and Vice versa ?

Ans : The PO role is focused on Product and the SM role is focused on people and process.

PO is having the full knowledge about the product, product management, value and quality of the product etc. The same should know by Scrum master then its ok to serve the role.

 

22) how can get the valuable product or how can give the much more value to the product ?

Ans : Value in Agile product development is about delivering features that meet customer needs and contribute to business success. To maximize value, a Product Owner needs to understand the market / competitors, customer needs and business goals by using prioritisation techniques. As I have used to with MoSCow Technique in my previous projects.

 

23) What is Backlog grooming and backlog refinement ? Is the same?

Ans : There is no difference between backlog grooming and backlog refinement. The terms are interchangeable. Backlog refinement has gained popularity in recent years and is now commonplace among many teams. Backlog grooming, also referred to as backlog refinement or story time, is a recurring event for agile product development teams. The primary purpose of a backlog grooming session is to ensure the next few sprints worth of user stories in the product backlog are prepared for sprint planning.

 

24) As a Scrum Master, what is your main aim to provide a valuable product ?

Ans : The scrum master's main objective is to make sure the team works according to the agile values. That they have the resources, time, and disruption-free environment to succeed. Let's discuss what this looks like in practice by reviewing the key aspects of the scrum master's role. A Scrum Master can help the team manage their flow of work by identifying and removing non-value added work to shorten their time to market and increase their ability to innovate

 

25) Conflicts happened then how you will resolve it ?

Ans : One of the best ways to resolve a conflict is by giving personal coaching to the members of the team. As a Scrum Master, it is very important to have a good relationship with the team members and guide them when they go through any impediments.

Understand it: In order to uncover the root cause, facilitate an open group discussion where team members feel safe to voice their concerns. Handle it: Employ conflict resolution methods such as mediation, negotiation, or, if necessary, bring in a professional facilitator.

 

26) As a SM, what impediment you have faced and how you have tackled it ?

Ans : Common examples of impediments for a Scrum Team include:

• Shortage of relevant skills or knowledge on a team
• A lot of technical debt
• Adverse team dynamics
• Lack of management support
• Inability to make decisions because of lack of empowerment
• Dependencies on other teams or external sources
• Technical issues, like access to tools, networks being down and broken laptops
• Bureaucracy, e.g. distractions from legacy processes

As a Scrum master, your role is not to solve the impediments yourself, but to empower and support your team to do so. You should also encourage your team to be proactive and creative in finding ways to overcome the impediments, and to learn from them for future improvement.

How to help the team address impediments :

As a Scrum Master you can facilitate the process of identifying and addressing impediments by encouraging the team to share their concerns and collaborating on solutions to overcome them. Here are a few suggestions.

1. Identify Impediments

You can help support the team and dig deeper by asking questions like:

• Is this a recurrent impediment? 
• What do we need to resolve this impediment ourselves? Is it within the control of our team?
• If we cannot resolve the impediment within the team, what steps can we take to resolve this? Who do we need support from?
• Is the impediment part of a wider issue? How can we find out if the impediment is part of a wider issue?
• What is the current impact of the impediment on our ability to deliver value? 
• What will be the impact of the impediment if we do not deal with it? Or, what would be the risk if we can’t solve the impediment?
• Should we tackle this impediment?

2. Create transparency around impediments

Visualize and track impediments on a (virtual) board or wall that is easily accessible to everyone involved. They may even choose to make this publicly available to encourage wider conversation and support. This could be the existing Scrum Team’s board, which may be especially useful to highlight obstacles that block work that is within the Sprint. 

One way to gauge the impact of an impediment is to refocus the team on their Sprint and Product Goals. This will help the team see if the impediments are truly an issue for at least the current Sprint.

3. Encourage the team to proactively resolve their own problems

Some teams fall into a pattern of believing that they cannot change or influence things in their work environment, which can cause a sense of helplessness among team members.  As a Scrum Master you can encourage teams to take a proactive approach instead by focusing on what is within their control so they can solve the problem. Additionally, help teams to explore how they can expand their sphere of influence for those impediments that are currently out of their control with an exercise such as The Circle of Influence and Control. As a result the team builds a stronger sense of ownership over their impediments and team members may be more motivated to improve continuously. 

 

 

27) How SM know, your User story is perfect?

Ans : The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).

A good user story should be:

• “I” ndependent (of all others)
• “N” egotiable (not a specific contract for features)
• “V” aluable (or vertical)
• “E” stimable (to a good approximation)
• “S” mall (so as to fit within an iteration)
• “T” estable (in principle, even if there isn’t a test for it yet)

 

28) what you will do as a SM, if one of the person is not listening or responding, working well in the scrum team ? What actions will take ?

Ans : You could ask them questions around their expectations and help them to understand that the team has not reached the maturity or velocity necessary to achieve the expectations that are being set.

Last option is “ to escalate” the things to higher management.

 

29) How do you follow scrum in your project?

Ans:

• Define the scrum elements. ...
• Prioritize the list of work or 'Backlog' ...
• Plan the scrum sprints. ...
• Establish transparency and conduct daily meetings. ...
• Review and retrospective of the sprint. ...
• Immediately start with the next sprint.

 

With Explanation :

Here are some ways to follow Scrum in a project: 

• Define the team: A Scrum team is made up of 5–9 members. 
• Set goals and objectives: Goals should be realistic and achievable, while objectives should be actionable and measurable. 
• Create a backlog: The backlog contains epics, user stories, and tasks. Epics are high-level requirements, user stories are more detailed requirements, and tasks are broken down from the user stories. 
• Plan sprints: Sprints are time-boxed iterations that last between 7–30 days. Each sprint starts with a planning meeting and ends with a review meeting. 
• Estimate tasks: Estimate how much time each task will take. 
• Assign ownership: Assign tasks to the appropriate team members. 
• Hold daily meetings: Hold daily Scrum meetings. 
• Review sprints: Review the sprint increment with stakeholders. 
• Remove obstacles: The Scrum Master is responsible for identifying and removing obstacles that prevent the team from completing their work. 
• Keep the iteration length fixed: This gives the development team feedback on their estimation and delivery process.

 

30)  What will do in the Daily Standup meeting ?

Ans : Agenda having 3 questions as below :

n  What we have done yesterday? Completion status

n  What we are going to do today? Planned for today

n  If anyone is facing any issues while completing the tasks, then we can see how we can help that person to resolve

 

31) If someone sit in US and you are in India, then how you plan/ schedule the Meetings/Events of scrums :

Ans : We always chose the overlapping time of shifts of working.

 

32) five Scrum ceremonies that make up a Sprint?

Ans :

·        Sprint Planning.

·        Daily Scrum.

·        Sprint Review.

·        Sprint Retrospective.

·        Backlog Refinement.

 

33)  When we can schedule the Sprint Review and Retrospective meeting ?

Ans: The Sprint Retrospective meeting happens after the Sprint Review meeting.

Sprint Retrospective is the last meeting of the sprint or cycle. The scope of actual improvement is discussed regarding people & relations, processes & practices, and the Definition of Done.

 

34)  In Retrospective meeting, which points , feedback you will get ?

Ans : During a retrospective meeting, you can expect to receive feedback on a variety of topics, including: 

·        Communication and collaboration: How effective was the team's communication and collaboration processes? 

·        Challenges: What challenges or obstacles were faced during the sprint? 

·        Team morale: What is the overall morale and satisfaction of the team? 

·        What went well: What went well during the sprint? 

·        What went wrong: What went wrong during the sprint? 

·        Biggest enablers: What were the biggest enablers during the sprint? 

The purpose of a retrospective meeting is to evaluate the previous sprint, iteration, or work item, and then create a plan to improve the team's work. The outcome of a retrospective meeting is typically an action plan to prevent the same issues from happening again. 

Some tips for running an effective retrospective meeting include: 

·        Encouraging honesty and openness 

·        Ensuring that all feedback is constructive and solution-oriented 

·        Gathering data about the project or work cycle 

·        Using the "What Went Well" framework to focus on objective outcomes 

 

35)  Who will participate in retrospective meeting?

Ans: The following people can participate in a retrospective meeting: 

·        Scrum team: The entire scrum team, including developers, testers, and other relevant team members 

·        Scrum master: The facilitator of the meeting, also known as the Scrum team leader 

·        Product owner: Represents the project's stakeholders and objectives 

·        Other contributors: Designers, marketers, or anyone else who contributed to the current sprint or iteration 

The goal of a retrospective meeting is to analyse the latest sprint and determine what changes can be made before starting the next portion of the project.

Tool like : IdeaBoardz - Brainstorm, Retrospect, Collaborate

 

36) How you will make retrospective more effective ?

Ans: The 6 steps needed for a successful retrospective are:

1.     Prepare with the right tools and participants.

2.     Start off the retro with an icebreaker.

3.     Review the project and cover the highlights.

4.     Look for insights and common themes.

5.     Decide on next steps.

6.     Wrap up the retro and follow-up.

Here are some tips for making retrospectives more effective: 

·        Create a safe space: Make sure your team feels safe and secure by keeping the attendee list minimal, encouraging open communication, and having a designated person run the meeting. 

·        Prepare: Have a clear picture of what went well, what didn't, and what you want to bring to the table. 

·        Gather data in advance: Give people more time to think about their input by gathering data before the meeting. 

·        Encourage sharing feedback: Listen actively, ask questions, and summarize the team's feedback. 

·        Have a facilitator: A good facilitator knows when to let open discussion continue or when to move to a game or exercise. 

·        Create a structured agenda: An agenda provides guidelines on how the meeting should proceed so discussions stay focused and on-topic. 

·        Look for insights and common themes: Identify strengths and areas for improvement. 

·        Decide on next steps: Brainstorm possible solutions, group similar or duplicate items, and hold a vote. 

·        Make retrospectives a habit: Establish a cadence for your retrospectives and stick to it. 

·        Think outside the office: A new environment can help fuel creativity and promote deeper thinking.

 

37)  When and what is product Refinement meeting ?

Ans : Product backlog refinement—in the past called backlog grooming in reference to keeping the product backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.

Here are some things to know about product refinement meetings: 

·        Purpose: The meeting's purpose is to ensure that the backlog items are prioritized, estimated, and ready for the upcoming sprint. 

·        Who attends: The product owner and the development team attend the meeting. 

·        When to hold the meeting: The meeting is usually held before each sprint planning meeting, which is typically every two weeks. 

·        How long the meeting lasts: Most teams need about 30 minutes to walk through the process. 

·        How to run the meeting: Some tips for running an effective meeting include timeboxing refinement of individual items and not letting unproductive conversations go on for more than five minutes.

 

38) What is the Important Event in the scrum ?

Ans: Every event is important, but As per my perspective – sprint retrospective

So, although each scrum event is important and the scrum framework works great when each event is treated with equal opportunity, if I had to draw down on which of those events is the most important to the development of an agile team, it would hands down be the sprint retrospective.

The sprint retrospective is possibly the most valuable event that the Agile world has within it, an event where the team come together and evaluate what is working, what needs work, where and how the team can improve in the next sprint. It's a time to reflect, inspect and adapt.

 

39)  If given the opportunity, to remove the event, then which you can remove?

Ans: I feel, nothing can be remove. If we remove anyone, then it will impacted on delivery of the valuable product.

 

40)  What is “DEEP” in product backlog ?

Ans : We use the four-letter abbreviation DEEP to describe the characteristics of a good product Backlog.” Thus, the team “DEEP” is a descriptive acronym for the quality of a product backlog in Scrum that stands of: 

n  Detailed appropriately : Items are described in a logical manner, with more detail for higher priority items and less detail for lower priority items.

n  Emergent : A product backlog should evolve, adding new items as we learn more about the problem space.

n  Estimated : A product backlog is a planning tool and helps organize development resources available.

n  Prioritized : Prioritize the backlog items

It's a simple tool that product owners or product managers can use to manage the product backlog and user stories effectively.

 

41)  What are the 3 C’s :

Ans: The 3 C's in scrum are card, conversation, and confirmation, which are used in the user story process: 

·        Card

The initial idea for the user story is written on a physical card or sticky note. This helps ensure the user story is clear and concise, and that everyone understands the user's needs. 

·        Conversation

After the card is written, the team discusses the user story to achieve a shared understanding. This stage encourages collaboration and ensures everyone is working towards the same goal. 

·        Confirmation

The final stage, where the team solidifies plans to move forward. The confirmation criteria help ensure the user story is well-defined and that everyone knows when it is complete. 

 

42)  How Scrum Master sure about the requirements, are correct or not ?

Ans : In Scrum, requirements are gathered collaboratively through interactions between the Product Owner, development team, and stakeholders.

 

43) What is DoR, Dod & Acceptance Criteria? What is difference between them?

Ans :

DOR:  ( PO Responsible)

- All requirements clear
- UX/ Figma should be given for all the scenarios
- No dependency on other tickets
- Acceptance criteria should be listed and clear to everyone

 

DOD (  Dev )
- All the points in Acceptance criteria are implemented
- No open High/Critical defects
- Code reviews done
- Code review comments should in closed by developer
- Unit testing completed
- UI/Implemented code should match with the UX Design/ Figma
- Code coverage % should not drop below threshhold
- For UI stories Responsive and Mobile UI should be implemented

- Jira board should be updated along with story status and time logged

 

DoR & DoD both are specific to scrum team

 

Acceptance criteria:

 

- specific to story, PO make sure 

- In Agile, acceptance criteria refer to a set of predefined requirements that must be met to    

   mark a user story complete.

 

NOTE: ALWAYS GIVE EXAMPLE OF YOUR PROJECT. 

n  Given

n  When 

n  Then 

 

44)  What is Spike ?

Ans : Spike is the name for a timeboxed user story or Task that is created in order to research a question or resolve a problem.

Spikes focus on gathering information and finding answers to a questions, rather than producing a shippable product.

 

Identified in Product Backlog Refinement meeting.

Outcome - POC: Proof of Concept

 

45)  What is WSR ?

Ans : Weekly status report (WSR)

You can share these reports with immediate team members, project managers, resource managers, or project stakeholders.

They provide a comprehensive view of the project's overall progress. The weekly status report contains more explicitly detailed information compared to other status reports.

Content :

 

Related to Team : Banckend – Frontend Developers , DevOps, QA, Scrum

 

A scrum weekly status report (WSR) should include the following information:

·        Summary: A clear summary of the week's progress

·        Accomplishments: Highlight key accomplishments

·        Challenges: Address challenges and solutions

·        Priorities: Outline upcoming priorities

·        Pending items: List pending items

·        Obstacles: List obstacles

·        Future plans: Outline future plans

46)  Story Points depends on ?

Ans :

n  Design

n  Coding

n  Unit Testing

n  Integration Testing

n  User Acceptance Testing

n  Expertise

 

 

47) How you do the estimation ?

Ans : The way Scrum teams estimate effort is through story points, a relative scale that allows for a more abstract and flexible approach compared to traditional hours-based estimation.

Each product backlog item is assigned a story point value, representing the perceived complexity and effort required.

 

Two tools :

 

Planning Poker

is a relative, consensus-based estimation technique in which the Agile or Scrum team estimates the efforts required for the backlog items (or user stories) by assigning story points. The team uses numbered poker-styled cards, where the sequence of the numbers is based on the Modified Fibonacci sequence, i.e., 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. The process involves discussing the user stories collaboratively and then providing individual estimates all at once. Afterward, the team finalizes the team's estimate by consensus.

 

How its work :

 

1.     The team gathers to discuss and estimate product backlog.

2.     Each development team member is given a set of poker cards, with each card containing a number of the Modified Fibonacci sequence to represent a story point.

3.     The Product Owner narrates the first user story to the meeting participants.

4.     After listening to the user story, the development team starts the discussion around different points, such as development strategy, potential risks, challenges, etc.

5.     After discussion, every member secretly picks a poker card, representing their estimate of the effort (story point) required to complete the task.

6.     All members show their cards simultaneously.

7.     If there are some major variations, then the team does a discussion again and re-estimates. Eventually, the team reaches a consensus and finalizes the team estimate for that user story.

8.     The above steps continue until the team completes the estimate of all user stories.

 

 

T-Shirt Sizing

is another relative agile estimation technique, which is similar to Planning Poker in many areas. In this technique, the team uses t-shirt sizes, i.e., XS, S, M, L, XL, and XXL, to estimate user stories. The team collaboratively discusses user stories and then assigns t-shirt sizes to reflect the efforts. For example, a user story with a medium "M" size means that it requires more effort compared to a story with a small "S" size. In short, it offers a simpler way to estimate user stories.

How its work :

1.     The team gathers to discuss and estimate product backlog.

2.     Each development team member is given a set of cards with t-shirt size labeling, i.e., XS, S, M, L, XL, and XXL.

3.     The Product Owner narrates the first user story to the meeting participants.

4.     After listening to the user story, the development team starts the discussion around the user story.

5.     After discussion, every member picks a t-shirt card, representing their estimate of the effort (story point) required to complete the task.

6.     All members show their cards simultaneously.

7.     If there are some major variations, then the team does a discussion again and re-estimates. Eventually, the team agrees on one size.

8.     The above steps continue until the team completes the estimate of all user stories.

 

48)  Why Fibonacci series?

Ans : The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34 and so on.

In Agile projects, this series is modified. The modified Fibonacci series is 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 - a sequence that is used to estimate the relative size of User Stories in terms of Story Points.

"Size" is not a simple estimate of how long a task will take. Instead, it's a shared idea of: Scope.

 

49)  What are Scrum Metrics and KPIs?

Ans : Scrum metrics and KPIs are part of a broader family of agile KPIs. Agile metrics include lean metrics, which focus on the flow of value from an organization to its customers, and Kanban metrics, which focus on workflow and getting tasks done. While most agile metrics are applicable to scrum teams, scrum-specific metrics focus on predictable software delivery, making sure scrum teams deliver maximum value to customers with every iteration.

Scrum KPIs have three major goals:

·        To measure deliverables of the scrum team and understand how much value is being delivered to customers.

·        To measure effectiveness of the scrum team; its contribution to the business in terms of ROI, time to market, etc.

·        To measure the scrum team itself in order to gauge its health and catch problems like team turnover, attrition and dissatisfied developers.

Ø  Scrum Metrics—Measuring Deliverables

The following metrics can help measure the work done by scrum teams and value delivered to customers:

1. Sprint Goal Success

A Sprint Goal is an optional part of the scrum framework. As defined by Scrum.org, it answers three questions: Why are we carrying out the sprint? How do we reach the sprint goal? What metric tells us the goal has been met? For example, a goal might be delivering a feature, addressing a risk, or testing an assumption.

By defining sprint goals and then measuring how many sprints met the goal, you can get a qualitative assessment of a scrum team’s work. Not just how many story points are completed, but how frequently the objectives of the business are met.

2. Escaped Defects and Defect Density

Escaped defects is a crucial metric that shows how many bugs were experienced by users in production. Ideally, a scrum team should fully test stories and completely avoid escaped defects. In reality, this rarely happens, but the trend of escaped defects is a good signal of product quality.

Defect density is also worth watching—it measures number of defects per software size, for example per lines of code (LOC). While this metric can easily be skewed, it is valuable in fast-moving projects to check if growth in defects is “normal” given the growth of the underlying codebase.

3. Team Velocity

Velocity measures how many user stories were completed by the team, on average, in previous sprints. It assists in estimating how much work the team is able to accomplish in future sprints.

While velocity is a key metric to watch in any scrum project, experts warn against using it as a goal, or using velocity to compare teams to each other. Velocity is a subjective measure (based on each team’s definition of story points) that captures the team’s progress. Trying to artificially increase velocity can act to erode trust and reduce transparency between teams and management.

4. Sprint Burndown

The sprint burndown chart is the classic representation of progress within a sprint. It shows the number of hours remaining to complete the stories planned for the current sprint, for each day during the sprint. The sprint burndown shows, at a glance, whether the team is on schedule to complete the sprint scope or not.

Ø  Scrum Metrics—Measuring Effectiveness

The following metrics can help assess the effectiveness of scrum teams in meeting business goals:

1. Time to Market

Time to market is the time a project takes to start providing value to customers, or the time it takes to start generating revenue. The first can be calculated by taking the length of the number of sprints before a scrum team releases to production. The second could be longer, depending on the organization’s alpha and beta testing strategy.

2. ROI

Return on Investment (ROI) for a scrum project calculates the total revenue generated from a product vs. the cost of the sprints required to develop it. Scrum has the potential to generate ROI much faster than traditional development methods, because working software can be delivered to customers very early on. With each sprint, scrum teams create more features that can translate into growth in revenue.

3. Capital Redeployment

Capital Redeployment measures if it’s worthwhile to continue a scrum project, or if the economic value of the project now exceeds its costs. In this case the team should be redeployed to other, more profitable projects.

To determine Capital Redeployment, calculate the revenue value of the remaining items in the project backlog (V), the actual cost (AC) of the sprints needed to complete those items, and the opportunity cost (OC) of alternative product work the team could do. When V < AC + OC, the project should end and the team redeployed to other projects.

4. Customer Satisfaction

There are several well-known metrics used to measure customer satisfaction. One is the Net Promoter Score (NPS), which measures if users would recommend the software to others, do nothing, or recommend against it. Using a consistent customer satisfaction metric and measuring it for every release indicates whether the scrum team is meeting its end goal—to provide value to customers.

Ø  Scrum Metrics—Monitoring the Scrum Team

These metrics can help a scrum team monitor its activity and identify problems early on, before they impact development:

1. Daily Scrum and Sprint Retrospective

These two scrum events, if carried out regularly with well-documented conclusions, can provide an important qualitative measurement of team progress and process health.

2. Team Satisfaction

Surveying the scrum team periodically to see how satisfied they are with their work can provide warning signals about culture issues, team conflicts or process issues.

3. Team Member Turnover

Low turnover (replacement of team members) in a scrum team indicates a healthy environment, while high turnover could indicate the opposite. Also contrast this metric with overall company turnover, which can impact the scrum team.

 

50)  Scrum Reporting—Which Metrics to Report to Stakeholders?

Ans : The most important thing stakeholders need to know about your scrum project is whether it is on track. The following metrics might help communicate this, and explain deviations from the expected project path:

·        Sprint and release burndown—Gives stakeholders a view of your progress at a glance.

·        Sprint velocity—A historic review of how much value you have been delivering.

·        Scope change—The number of stories added to the project during the release, which is often a cause of delays (many agile tools can show this automatically).

·        Team capacity—How many developers are on the team full time? Has work capacity been affected by vacations or sick leave? Developers pulled off to side projects?

·        Escaped defects—provides a picture of how your software is faring in production.

51)  In which scenario Burn-down chart goes up ?

Ans : In two scenario it count be happened :

Ø  User story estimation was wrong

Ø  PO has added more requirements in the Product backlog – scope change

 

52)  When Burn-up chart goes down ?

Ans : If user story Re-opened

 

53)  What is Velocity Graph :

Ans : A velocity-time graph is a graph that shows how an object's velocity changes over time. It's used to understand an object's motion, including its velocity, direction, acceleration, and displacement. 

Here are some things you can learn from a velocity-time graph: 

·        Acceleration: The slope of the graph indicates the acceleration of the object. A flat line indicates constant velocity, while a sloped line indicates constant acceleration. 

·        Displacement: The area under the graph is equal to the object's displacement during the time period covered by the graph. The area can be a triangle, rectangle, or trapezoid. 

·        Velocity: The graph shows the velocity of the object at any given time.

 

54)  What is Velocity ?

Ans : In Scrum, velocity is a metric that measures the amount of work a team can complete in a sprint. It's calculated by dividing the total number of story points completed by the number of sprints. For example, if a team completes 70 points over two sprints, their velocity is 35 points per sprint. 

Here are some things to know about velocity in Scrum: 

·        Calculation : To calculate velocity, only include stories that are marked as "Done". Don't include incomplete or partially completed work. 

For instance, if the Scrum Team has finished a total of 80 points over 4 Sprints then the actual velocity of the team would be 20 points per Sprint.

Actual Velocity : Story points 80 / 4 sprints = 20 points per sprint

·        Accuracy : For a more accurate velocity, use the average of the last three to five sprints. 

·        Use : Velocity helps teams estimate the scope and delivery date of a product. It also helps with sprint planning by predicting how many user story points a team can deliver. 

·        Improvement : Some ways to improve velocity include: 

·        Defining clear sprint goals 

·        Planning sprint capacity 

·        Implementing agile engineering practices 

·        Conducting sprint reviews 

·        Performing sprint retrospectives 

·        Monitoring and tracking sprint metrics

 

55)  Difference between sprint velocity and team velocity in scrum?

Ans: In Scrum, sprint velocity and team velocity are both metrics used to measure how much work a team can complete in a sprint, but they're calculated differently: 

·        Sprint velocity

The average number of tasks or hours a team completes in a sprint. It's calculated by dividing the number of tasks completed in previous sprints by the total number of sprints. 

·        Team velocity

The average number of points a team completes per sprint, based on the total points for all fully completed user stories. It's calculated by dividing the number of backlog items or user story points delivered by the total number of days in the sprints. 

Velocity is an estimate of how much progress a team has made in the past. Teams use their velocity to plan their upcoming sprints. Velocity is influenced by the size and complexity of user stories.

 

56) What is Capacity Planning :

Ans : Capacity planning is a practice in agile project management that helps determine how much work a scrum team can handle in a sprint. It helps teams balance underutilization and overloading. 

Here are some things to consider when doing capacity planning in scrum: 

·        Calculate capacity

To calculate capacity, you can multiply the number of workdays in a period by the number of working hours per day. Then, subtract the total number of work hours used for team meetings. 

·        Consider team size

Capacity planning takes into account factors like team size, individual skills, and other commitments. 

·        Calculate capacity loss

To calculate capacity, you can subtract the capacity loss for the upcoming sprint from the maximum capacity. 

·        Calculate the ratio

To calculate capacity, you can get the ratio of adjusted capacity to the maximum capacity. 

Capacity planning is important because it helps ensure that the right resources are available when needed. These resources can include people with the right skills, time, or budget.

 

57)  Different Types of Reporting Charts ?

Ans :

1. Sprint Burndown

At a Sprint-level, the burndown presents the easiest way to track and report status (the proverbial Red/Amber/Green), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide near-real time updates on Sprint progress.

“If your team do it right, then they would take in just the right amount of work into a sprint.”

At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart.

The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into a sprint. And if everything goes well, the burndown trend will look like this:

Figure 1: Ideal Sprint Burndown Chart

 

Of course, not all sprints are made equal. So actual Sprint Burndown may not look as perfect.

For instance, Scrum teams are prone to overestimate their ability to deliver during their first development Sprint on a new project. Or if they are a newly formed team. Or if they are learning to work Scrum. In such cases, it’s quite possible that the team fall behind schedule. The burndown chart helps bring issues to the surface:

Figure 2: When the team are off track during a Sprint

As you can see, this particular team needed a spike late in the Sprint to catch up. This is not uncommon, and the reasons could be many – the team overestimated, or development stalled due to technical constraints. Ideally, such trends should be avoided.

2. Sprint Velocity

This metric goes hand in hand to help your team achieve ideal Sprint burndown.

How?

In simple words, Sprint Velocity represents the average number of story points a team can take on for a Sprint. This number is based on observing how many story points were delivered during the previous two to three Sprints, and simply calculating the average story points delivered per sprint.

When you know your team’s velocity, it is then going to be easy to manage how much work they can commit to at the beginning of a Sprint. Keeping track of Sprint Velocity will help you and your team avoid situations where you need to reduce or change scope mid-sprint – which may not make them (or you) look good.

The obvious limitation with Velocity is that you need at least two to three Sprints’ worth progress before you can identify a trend.

When it’s too early to know your team’s Velocity.

During the first few sprints, I try to avoid the off track scenario (like in Figure 2 above) by looking at velocity from past Agile projects my team have been part of.

Where velocity data is available for past (similar) projects, and if the team are experienced enough in Agile to employ consistent story pointing across projects, then you can begin new projects like a boss, and get the team to accept reasonably accurate story points right from the get go.

Again, velocity can differ between projects – even for the same team. So while this technique might improve accuracy in Sprint Planning during the first few sprints, it is not fool proof. So there’s that.

3. Epic, Product and Release Burndown

We know now that Sprint burndowns help you track status at Sprint-level. Epic, Product and Release burndown charts provide a similar utility.

Figure 3 – Sample Release Burndown Chart

As with Sprint burndown, Release-level burndown charts help you understand when you can expect to deliver a given scope. And again, note that the accuracy of the burndown improves with time, as the team deliver the first few sprints.

“It is quite rare for Agile projects to have the entire scope nailed right at the beginning (like Waterfall), so learn to accept spikes as a matter of course.”

As you can see from Figure 3, the sample release burndown is not an ‘ideal’ trend line like Figure 1. Around Sprints 2 and 3, the team have (seemingly) added new requirements to the release backlog. This has led to a spike in the blue line around sprint 3, before settling back to a more stable burndown trend.

Any experienced Agile practitioner will tell you such spikes in the burndown trend line are quite common in real life Agile projects. By nature, Agile allows you to groom the backlog regularly to increase or decrease scope. It is then only natural that such grooming reflects in your burndown charts. It is quite rare for Agile projects to have the entire scope nailed right at the beginning (like Waterfall), so learn to accept spikes as a matter of course.

Or, Use Burnup Charts instead

There are limitations with Burndown charts. They don’t bring out issues such as scope creep as clearly for all stakeholders to understand.

Why is this important?

Let’s take the release burndown depicted in Figure 3 earlier as a case in point. The spike around sprint 3 depicts what looks like a bit of scope creep. This has led to a not-so-straight trend line, with a projection that is delivering noticeably later than the team could have before the spike. The impact of the change in scope isn’t entirely clear to an onlooker.

For a senior stakeholder that sits outside the project, it may not be immediately apparent that the team are doing more than they set out to plan. Therefore, the causes for any delays in the project schedule aren’t understood as well as they could be with better information.

A burnup chart could help you here. Let’s see how with an example:

Figure 4 – Sample Burnup Chart

Credit

A burnup chart plots two key pieces of information – total work (hours, story points etc.) and completed effort (progress against total work). In the example in Figure 4, you can see that the Scope (i.e., total work) changes constantly (red line). In fact, it is expected to have changed as much as 30% by the end of the iteration (sprint).

You can also see that actual effort has progressed steadily along the blue line. From a quick glance, the following will be clear to anyone:

·        The scope of work for the iteration (sprint) has changed by as much as 30% through the iteration.

·        The team set out to deliver 140 hours’ effort, and are on track to deliver 160 – i.e. they are delivering about 15% more than they originally committed.

·        Despite the increased productivity, the team will still fall short of the (changed) scope for the iteration (sprint).

What possible actions could be considered?

·        Better scope management – so the team don’t have to factor changes day-to-day, and therefore lose effort in realigning with new scope constantly.

·        Better upfront iteration (sprint) management – so the product owner can work with the team more effectively to produce a more concrete sprint backlog at the beginning of the iteration (sprint).

Now, could you have surmised all that with just the green line in figure 4, or the spike in the blue line in figure 3? Highly unlikely. That is the power of the burnup chart.

Choose burnup or burndown mindfully – or better yet, choose both!

When your release/sprint scope isn’t stable enough, switching from a burndown to a burnup chart will help you identify and report risks and issues more effectively. If on the other hand, your backlog is pretty stable up front, and you don’t see the scope changing regularly, burndown charts will be sufficient to report progress.

4. Earned Value

Now this is one of the Agile reporting techniques I am just a little hesitant to recommend.

Let me explain.

If you don’t know Earned Value reporting, it’s basically about measuring whether the amount of money spent through so far in your project justifies the amount of work completed at this point in time.

There are a few variables here:

1.     Budget – the estimated cost of your project. This is usually decided at the beginning of the project, and reviewed infrequently or not at all.

2.     Actual cost (AC) – the proportion of the original budget your team have spent so far.

3.     Planned Value (PV) – the proportion of your project scope that was expected to have been delivered by this time.

4.     Earned Value (EV) – the ‘real’ value of the scope that has actually been delivered so far.

Let’s consider the sample EV graph below:

Figure 5: Sample Earned Value Graph

Credit

At t1, the team has delivered more Earned Value compared to budget spent (Actual Cost), so EV > AC.

At t2, the team has delivered less Earned Value compared to budget spent (Actual Cost), so EV < AC.

What does this imply?

Not much, really – or a lot, depending on your situation.

If for example, you’ve technically only delivered 50% of your project scope but already spent 60% of the original budget,

·        This could mean your team aren’t efficient – after all, you’ve spent more than you earned.

·        It could also mean you budgeted incorrectly in the beginning – being Agile and all, the initial budget would have been a ballpark estimate.

·        Again, it could be that your team have completed much foundation work during the initial phases of the project that ultimately, EV will catch up to AC.

·        Or, your scope could have changed substantially to justify the additional spend (re-alignment) at the given point in time.

Unless you truly understand the root cause of a variance in EV vs AC, it will be hard to judge whether your Earned Value at a point in time is acceptable. Especially given the nature of Agile projects in general, it is unfair to expect the level of certainty necessary to get budget and scope right up front.

So use this metric – if only to keep an eye on how much money your project is spending relative to progress. Just don’t rely too much on it – it might take you back to Waterfall. Which isn’t a bad thing in itself – however, be careful not to confuse Agile and Waterfall.

5. Scope Change

This is a bit of an oxymoron. By nature, Agile projects should be open to scope change. Right? Right?

Yeah, not so much.

If your project is in churn all the time, you’ll find your team constantly working to re-align with new requirements, dropped requirements, changes etc. If the project scope reduces significantly as part of all this churn, it could mean you can deliver earlier than planned. If on the other hand, there is significant addition to scope or if the scope has changed so much you need a lot of rework, then all of a sudden, your project could be in the red because the original schedule now looks like Mt. Kilimanjaro.

So what do you do in such scenarios?

You report the changes to scope regularly, of course. Agile projects can absorb changes to scope. They should also report such scope changes diligently.

Did your Product Owner drop Feature number 4 mid-flight and bring in a Feature number 6 that costs twice as much – in time and money? You need to report this so you can secure the additional funding and time necessary to absorb the changes.

By reporting Scope Changes, you demand a certain level of responsibility on the part of the Product Owner. They have the responsibility to think any significant changes through before these are introduced to the project, so they can be prepared to answer any questions about cost/scope creep.

6. Defects Trend

Plot defects as they are identified, their resolution and those that remain open on a graph, and you’ll have yourself a visual Defects Trend chart. Defects Trends are useful in tracking defects resolution for a release or product as a whole.

Not all defects may be fixed within the Sprint or Release they are identified. Some (usually non-blocker defects) tend to get carried into future Sprints or Releases.

Figure 6 – Sample Defects Trend

Plotting and tracking the Defects trend will help your team in a number of ways:

·        You can manage code quality as you get closer to a release.

·        The trend will help you decide if you need a Defects spike.

·        Making defects trends visual brings a sense of urgency and accountability among developers, who will (hopefully) work to improve code quality.

7. Team Capacity/Load

Whether you’re starting out with Agile Transformation, or if you’re at various stages of getting there, the most challenging Agile tenet is not having team members spread on multiple projects.

“Even more challenging is to know if everyone in your team is working to optimal capacity.”

While Agile doesn’t allow sloths to survive – it exposes them eventually – we’re not talking about work shirkers here.

You do genuinely need a way to know – at any point in time – what everyone in your team is up to. The Team Capacity/load dashboard can help with providing you a snapshot of your team’s workload.

How does it work?

For each team member on a project, capture the following information:

·        Total capacity in hours = number of hours per day that they are able to dedicate to the project multiplied by number of days that they are allocated to the project.

·        Assigned capacity in hours = number of hours (or story points multiplied by average number of hours per story point for the team member’s particular skill) allocated.

·        Available capacity in hours = Total capacity – Assigned capacity

Having this information to hand will help manage your team’s allocation better – especially when they are across multiple projects.

Tools like JIRA offer a number of plug-ins to manage Team Capacity/Load online, so you have on demand access to the latest view of work distribution and capacity.

 

58)  Risk Management in scrum ?

Ans : ROAM is a risk management model used in Agile organizations to identify and categorize risks. The acronym stands for Resolve, Own, Accept, and Mitigate. The four categories help ensure that all risks are being handled appropriately. 

Here's what each category means:

·        Resolved: The risk is no longer a threat and no further action is required

·        Owned: A team member is assigned to manage the risk because it can't be resolved immediately

·        Accepted: The risk can't be resolved, so it must be accepted as-is and dealt with as necessary

·        Mitigated: A plan is formulated to eliminate the threat of the risk 

 NOTE:

The ROAM model can be used at every level of an Agile organization, but risks that could affect the whole Agile Release Train (ART) should be escalated to the Program level.

 

59)  What is Technical Debt in scrum ?

Ans : Technical debt in Scrum is the result of actions that hinder a development team's ability to deliver features on time. It can occur when a team prioritizes speed over quality, or when they incur debt due to a lack of experience or knowledge. Some examples of technical debt include: 

·        Code that isn't refactored properly 

·        Insufficient tests 

·        Infrastructure that isn't up to par 

·        Forgoing work like writing clean code, documentation, and data sources 

Here are some ways to manage technical debt in Scrum: 

·        Code reviews: Have peers examine code written by team members to ensure quality 

·        Automate code quality checks: Automate checks to help identify issues early 

·        Make technical debt transparent: Build visibility into technical debt and set processes to pay it off 

·        Continuous integration and deployment: Integrate code changes frequently and automatically deploy them to test or production environments 

·        Record technical debt: Use a work management tool to record technical debt items

60)  What is Working agreement in scrum ?

Ans : A working agreement in Scrum is a set of guidelines that a Scrum team creates to help them work together. It's a tool used in the Agile work methodology to establish ground rules for a software development project. 

Here are some things to consider when creating a working agreement: 

·        Shared understanding : The agreement should capture the team's shared understanding of how they want to work together. 

·        Expectations : The agreement should help establish what's expected of each team member. 

·        Values : The agreement should consider the Scrum values of courage, commitment, focus, openness, and respect. 

·        Areas to cover : The agreement can include areas such as roles and responsibilities, processes and tools, norms and behaviours, and how to coordinate work pressure and stress. 

·        Revisiting and improving : The Scrum Master is responsible for ensuring the team revisits and improves their working agreements over time. 

 

62)  What is a Jira workflow?

Ans : In Jira, the path your issues take from creation to completion is called workflow. Each workflow is composed of a set of statuses and transitions that your issue moves through during its lifecycle and typically represents work processes within your organization. 

A Jira workflow represents the process your team uses to take an issue from creation to completion. The illustration below is an example workflow:

Jira workflows are composed of 3 unique elements:

1.     Status: A status indicates where the issue is within the workflow. Some examples may include: Open, In Progress, In Review, Scheduled, Pending, Waiting, etc.

2.     Transition: A transition represents the action being taken to move an issue from status to status. A transition is a one-way link, so if an issue needs to move back and forth between two statuses, two transitions need to be created.

3.     Resolution: When a task is completed and no longer open, it needs a resolution status. Some examples may include: Closed, Resolved, Shipped, Completed, Done, Finalized, Won’t Do, etc. (This is only available in company-managed projects).

61)  What is your workflow in Jira – scrum ?

Ans : To Do è WIP è In-Dev è In-QA è In-Review è Done

 

62)  in Jira, If I want to see, what are the pending work ?

Ans : Go to the issue & Filter

 

63) What is JQL (Jira Query Language) ?

Ans : Jira Query Language (JQL) is a query language used to search for issues in Jira, a project management tool. JQL is a structured way to search for issues, and it has its own syntax and vocabulary. 

Here are some things you can do with JQL: 

·        Search for issues: You can search for issues by specifying criteria like issue type, status, project, assignee, and custom fields. 

·        Create custom reports: You can create custom reports based on specific search criteria. 

·        Automate processes: You can automate processes within Jira. 

·        Save query results: You can save query results and use them as filters and views across Jira. 

Here are some examples of JQL queries:

·        Basic queries

project = “My Project”, assignee = currentUser(), status = “In Progress”

·        Advanced queries

Parent Link” IN (EX-000, EX-001, EX-002, EX-003), issuekey in portfolioChildIssuesOf(“INIT-001”) * “Team” = “shared team name”` 

You can create a custom filter in Jira using JQL by following these steps:

1.     Select … > Manage custom filters from your board or backlog

2.     Select Create custom filter

3.     Enter a name and description for your filter

4.     Enter a filter query using JQL

5.     Select Create once your query is validated

 

64)  Jira, Confluence used for ?

Ans : Confluence and Jira are tools that can be used together to help teams manage and organize agile projects: 

·        Workflows: Jira is good for planning and tracking project work, while Confluence helps organize content and ideas. 

·        Documentation: Confluence can be used to create and organize technical documentation, meeting notes, project plans, and more. 

·        Collaboration: Confluence can help teams collaborate and share content, knowledge, and ideas. 

·        Communication: Confluence can help improve communication between development teams and non-technical stakeholders. 

·        Single source of truth: Confluence can be used to create a single source of truth for software documentation. 

·        Embedding: Confluence pages can be embedded inside Jira. 

·        Tracking progress: Confluence can be used to track progress on the current release. 

 

65)  What is STAR Technique in scrum ?

Ans : The STAR method is a technique for structuring responses to behavioural interview questions in a Scrum Master job interview. 

STAR stands for Situation, Task, Action, and Result. Here's how to use the STAR method: 

·        Situation: Set the context by describing the situation or challenge you faced. 

·        Task: Describe your role or responsibility in the situation or challenge. 

·        Action: Explain how you handled the situation or overcame the challenge. 

·        Result: Quantify and describe your results. 

The STAR method helps you provide clear and concise answers to interview questions. You can use examples from work, home, or volunteering.

 

66)  What is Given-when-then (GWT) acceptance criteria?

Ans : Given-when-then (GWT) acceptance criteria is a syntax for defining the context, action, and expected outcome of a scenario. It's a popular technique in Agile development to define the expected behaviour of a user story. 

The format is made up of three parts: 

·        Given: Describes the initial context or state of the system 

·        When: Represents the action or event that triggers the behaviour 

·        Then: Outlines the expected outcome or result of the action or event 

Here's an example of GWT acceptance criteria: 

Ø  Scenario: Student has unfinished classes and requests class schedule 

·        Given: Student is logged into the website 

·        When: Student requests class schedule 

·        Then: Student's customized training plan is viewable 

The GWT format can be used for user acceptance criteria, user acceptance tests, describing business logic, and improving communication with stakeholders.

 

67)  MVP Vs MPP ?

Ans : In Scrum, Minimum Viable Product (MVP) and Minimum Marketable Product (MMP) are two key stages in the product development process: 

·        MVP : The first working version of a product, with just enough features to satisfy early customers and gather feedback. MVPs are used to validate ideas, test them, and draw conclusions. 

·        MMP : The next stage after the MVP, where the product is ready to be sold to the end user. MMPs are based on feedback from the MVP and are ready to hit the market for early adopters. 

Here are some other differences between MVP and MMP: 

·        Purpose : MVPs are used to test and validate a product's potential with a target market, while MMPs are used to launch a product and attract customers. 

·        Features : MVPs have minimal features, while MMPs have complete functionality. 

·        Focus : MVPs focus on building core features that solve customers' most pressing needs, while MMPs focus on attracting consumers and generating revenue. 

Examples : A food delivery app with basic functions is an example of an MVP, while Apple's iPhone is an example of an MMP.

 

68)  What is sprint 0 ?

Ans : In Scrum, Sprint Zero is a preparatory phase that takes place before the start of a project or a team. It's a set period of time that focuses on planning and preparation, rather than immediately jumping into development. The main purpose of Sprint Zero is to establish a solid foundation for the project by addressing critical preparatory tasks. 

Some activities that take place during Sprint Zero include:

·        Defining project goals

·        Clarifying requirements

·        Setting expectations

·        Developing a minimal number of user stories

·        Story mapping

·        Working towards Agile events

·        Updating the backlog 

Some recommend that teams instead of a Sprint Zero:

·        Commit to the sprint that delivers a valuable product increment for a customer or end-user

·        Include preparatory work in the sprint backlog as a priority

·        Start sooner than you are ready

 

69)  What is ScrumBan ?

Ans :  At a glance: Scrum, Kanban, and Scrumban

	Scrum	Kanban	Scrumban
Methodology	Fixed length sprints Fixed roles Consistent delivery	Limit work in progress Track tasks visually Continuous flow of work	Fixed length sprints Limit work in progress Track tasks visually Continuous flow of work
Roles	Product Owner Scrum Master Development team	None	None
Artifacts	Product backlog Sprint backlog Increment finished	Kanban board Kanban cards	Scrumban board Scrumban cards
Events	Sprint planning Daily standup Sprint review Sprint retrospective	Kanban meeting	Sprint planning Daily standup Sprint retrospective
Process flow	Product backlog Sprint backlog In progress Review Done	To Do In Progress Done	To Do In Progress Done

 

70)  XP methodology in Agile :

Ans : Extreme Programming (XP) is an agile software development framework that aims to improve the quality of software and the quality of life for the development team. It's considered to be the most specific agile framework for software development engineering practices. 

Here are some of the key aspects of XP: 

• Values: XP is based on five values that guide teamwork, including communication, simplicity, feedback, respect, and courage. 
• Practices: XP has 12 practices, along with five guiding values and five rules. 
• Activities: XP describes four basic activities that are performed within the software development process: coding, testing, listening, and designing. 
• Roles: XP defines six core roles for the team: customer, programmer, tester, tracker, coach, and consultant. 
• Life cycle: The XP life cycle is an iterative process that takes the team from the planning stage to the delivery of the final product. 
• Story cards: XP uses story cards to keep track of tasks. 
• Timelines: XP permits changes to predetermined timelines.

71)  As a Scrum Master, What is your achievement?

Ans : There's no success for the Scrum Master unless the team also succeeds, and for that we must learn to work with the team.

Working with the team means that we are constantly enabling the team, and not doing their work for them, not solving their problems for them, and not taking over their meetings for them.

As a Scrum Master, I have achieved many things, including: 

• Helping others excel: You can help create an environment where others can progress and master their careers. 
• Keeping teams organized: You can keep your team on track and focused on their projects. 
• Helping teams embrace Agile: You can help your team adopt an Agile mindset and work together as a self-managing team. 
• Increasing transparency and productivity: You can facilitate Scrum events like Daily Stand-ups, Sprint Planning, and Retrospectives to increase transparency and productivity. 
• Empowering teamwork: You can empower teamwork and collaboration. 
• Building trust: You can build trust with your team. 
• Having a clear vision: You can have a clear vision and help your team achieve their goals. 
• Improving estimates: You can help your team improve their estimates for time, cost, and effort. 

Some other ways to measure the success of a Scrum Master include: Delivery of value incrementally, Positive team dynamics, Focus on continuous improvement, and Empowered and self-managing team.

 

72)  How you will handle the situation, where stakeholder are not happy on deliverables ?

Ans : To avoid above situation,

Ø  Keep them involved and informed 

Ø  Make sure they are heard

Ø  Don't let them tell your team how to develop the product

Ø  They only care about getting the job done, but it's the Scrum team's job to do the job effectively and efficiently.

Ø  As long as the product is aligned with stakeholder's expectations, they should be happy.

 

73)  what formula, you can used to delivered project Metrix ?

Ans : Here are some formulas for calculating Scrum metrics: 

• Commitment reliability : This metric measures how reliable a scrum team's commitment is. The formula is: Commitment reliability = (accepted points/committed points) * 100. 
• Expected velocity : This metric is calculated by dividing the total estimated story points by the total number of planned sprints. 
• Scope change : This metric helps you track the number of stories added or removed during a sprint or release. The formulas for calculating scope change indicators are: Descope = (D/C) * 100 and Scope increase = (A/C) * 100. 
• Defect density : This metric measures errors in a specific software size, such as a specified number of code lines. You can measure your project's defect density per thousand lines of code (KLOC). 
• Throughput : This metric helps you assess the quantity of work across a time period. 

 

Other metrics include:

• Velocity
• Average velocity
• Defect rate
• Story points remaining
• Story points done
• Lead time
• Cycle time
• Response time
• Completed work

 

74)  What is Jira align tool ?

Ans : Jira is a project management tool that works at the level of a team. 

Jira Align works on a larger scale. It co-ordinates the work of multiple teams towards achieving common objectives set by the organisation. We used for SAFe methodology.

 

75)  In Fixerfive/current project, if PO is going to ask to add a new into backlog, then ?

Ans :

·       I will check , if its already in scope, then we will adjust and try to pick up in upcoming sprint Asap.

·       If, its totally new, then need to create “change request” and Also it will impact on budget, time also.

 

76)  What is Horizontal and vertical slicing in Migration scrum project ?

Ans : Horizontal and vertical slicing are techniques used in software development to break down work into smaller, more manageable parts. The best technique to use depends on the project's needs, and both can be useful in different situations: 

• Vertical slicing : This technique is recommended when it's important to deliver key functionality early, or when user feedback is crucial. It can help improve the scrum workflow by making stories easier to understand, estimate, and less risky. Vertical slices are often used for user stories, and can include changes to multiple architectural layers, such as the UI, business logic, and database. 
• Horizontal slicing : This technique is recommended when it's important to establish a robust infrastructure or reusable components. Horizontal slices break down features or functions into layers, and must be combined with changes in other layers to provide value to users. 

Both techniques can help Scrum teams deliver value quickly and reduce risk by breaking down work into smaller parts. 

 

77)  What is release note and who prepare it?

Ans : Development Team: Developers, testers, and QA professionals are instrumental in providing the technical details and context for the release notes.

They offer insights into the specifics of the changes, including new features, bug fixes, enhancements, and potential impacts on the user experience.

 

78)  Who will write User Acceptance Testing ?

Ans : UAT is a way to determine if the software meets the needs of your business.

Unlike with other types of testing, the actual users or the product owner carries out the software tests.

 

79)  As a scrum master, what is your strength & weakness?

Ans : explain as per requirement :

Scrum Master Strengths	Scrum Master Weaknesses
Good knowledge of Scrum and the industry	Will face resistance from individuals
Able to handle and interact with multiple disciplines	Has too much pressure with an ambiguous job title and lots of work
Can focus on quick launches of products by using sprints	Unable to manage new complex change requests
Communication and transparency help to build trust and resolve issues faster	Virtual teams can have many communication barriers

 

80)  What is your biggest learning in scrum master role?

Ans : Choose any one from below :

·        Effective communication: Clear and transparent communication is crucial. Scrum masters ensure all team members and stakeholders understand the project's status, goals, and obstacles.

·        Empathy: It is essential to understand and empathize with the team's challenges.

• Strong Scrum and Agile Training skills. A Scrum Master helps teams follow the guidelines of the Scrum framework. ...
• Organisational Skills. ...
• Tech Knowhow. ...
• Interpersonal Skills for effective communication. ...
• Adaptability. ...
• True Leadership.

 

81)  What is KPI and OKR in scrum ?

Ans : Objectives and Key Results (OKRs) and Key Performance Indicators (KPIs) are both goal-setting frameworks that can be used in Scrum, but they serve different purposes: 

• OKRs : OKRs are aspirational goals that focus on the process and steps needed to achieve results. They are often re-evaluated and adapted, and are developed through a participative process. OKRs are a good fit for Scrum because they help drive innovation, learning, and growth, and encourage a comprehensive approach to performance management. 
• KPIs : KPIs are quantifiable metrics that indicate the success or efficiency of processes. They are often defined top-down by management, and tend to remain consistent quarter-over-quarter. KPIs are a good fit for Scrum because they can be used to measure ongoing activities, and can help you understand if you're on track towards your goals. 

 

82)  What is 3^rd Party Vendor management ?

Ans : Vendor management is more than just doing the due diligence to select the right third-party suppliers and vendors for your business.

Besides selecting vendors and negotiating contracts, appropriate management includes cost control, reducing security risk, and ensuring service delivery.

 

83)  What is stakeholder Management ?

Ans : In Scrum, a stakeholder is anyone with a vested interest in the product who is not part of the Scrum Team.

As Product Owner, you can think of stakeholders as anyone with an interest in or an influence on the product. These are the people who'll help you discover, develop, release, support and promote the product.

Happy Learning and All the best for the Interview !!!!