Explore topic-wise InterviewSolutions in .

Frames of reference are everywhere. For example, if you are in the northern hemisphere and you look into the night sky, you will see the visible universe as a collection of stars grouped into constellations.  Now imagine a person in the southern hemisphere looking at the night sky; the person will still see the visible universe as a collection of stars grouped into constellations but they will be a different set; the 2 people have different frames of reference.

If the person in the southern hemisphere says to the person in the northern hemisphere “I think that there is something happening to the fourth STAR in the Southern Cross constellation”, the northern hemisphere person may not know what the other is talking about and certainly could not TELL if something was happening or not

We all have our own unique frames of reference for every subject in our heads; they are based on our experiences of childhood, PARENTING, education, religion, previous interactions with other people etc and even where we are physically located.

If you live in a country where there are words written in the road to warn you of something, like “SLOW”, if you are in a car, you will see the word SLOW ‘normally’ but if you were in a helicopter above the word you will see it vertically elongated.

It is the same sign but it is seen differently because of the different frame of reference for the viewers.

So why is this important to you?  When people are communicating the words and ideas that they express come from their own frame of reference and the potential for miscommunication is high if the frames of reference of the listener are not similar to that of the listener.  Imagine trying to describe a hippopotamus to someone who has never seen one; would you try an ANALOGY with something your listener had seen? Would you try to draw one? Not simple!

As a Scrum Master/Facilitator you need to be aware of different peoples’ frames of reference when they are communicating so that you can spot possible misunderstandings in listeners.

The participants in product development workshops will all have their own frames of reference from business and technical and even between people within the same skill set depending on their individual experience.

Listen for jargon and abbreviations in conversation and ensure that all listeners know what the speaker is talking about.

The ‘Groan Zone’
After a period of divergent thinking (see Q – What are ‘divergent’ and ‘convergent’ thinking? ), most groups enter a Groan Zone.

Having just ‘brainstormed’ a list, the next task, in theory, is simple; sift through the ideas and pick a few to discuss in depth. 

In practice that task can be difficult because everyone has their own frame of reference;  when people misunderstand one another, they become more confused, more impatient and possibly more self-centered; people repeat themselves, they interrupt, they dismiss other people's ideas and rudely put each other down.

Without a facilitator, at some point, the participants will agree to almost anything, any half-baked, unrealistic, mediocre compromise, just as long as it will get them out of the room.

One way to help workshop participants gain an understanding of each other's ideas is to encourage them to ask direct questions of one another and listen carefully to the answers. 

However, there are some challenges to this ‘simple’ approach:

• Some participants fear that asking questions MIGHT seem confrontational or rude
• Many people cannot cope with the ambiguity of unstructured inquiry and dialogue for very long
• It is hard for everyone to tolerate the poor behaviors and emotional turmoil that occurs when people feel misunderstood

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of the Scrum Guide; as a Scrum MASTER you should attend the events and ENSURE the team is following the ‘Transparency, INSPECT and Adapt’ processes: 

• Sprint Planning
  • Inspect the average Team Velocity over the previous 3 or 4 Sprints, ensure that the velocities have been Transparent to the team and ensure that the team Adapt the Velocity to be used for planning the Sprint
  • Inspect the Product Backlog (PB) and ensure that it is up to date, that it is Transparent to all stakeholders and that the team Adapts the PBI estimates if necessary
• Daily Scrum
  • Inspect the Team Board and Adapt the plan for the next day ensuring changes are Transparent to all the team
  • Inspect the Impediments Board and Adapt plans to resolve impediments if necessary
• Sprint Review 
  • Inspect the increment and Adapt the Product Backlog if necessary making sure that any changes are Transparent to all stakeholders
  • Inspect the Release Plan and Adapt it if necessary making sure that any changes are Transparent to all stakeholders
• Sprint Retrospective
  • Inspect the PROCESS that has been followed and make plans to Adapt the process if necessary making sure that any changes are Transparent to all team MEMBERS

The following is a quite comprehensive list of attitudes and skills that contribute to being a great Scrum Master; of course you don’t have to meet this entire list to be a great Scrum Master; consider it as some inspiration on areas you might want to RESEARCH. 

• Involves the team with setting up the process. A great Scrum Master ensures the entire team supports the implemented Scrum process.
• Understands team development. A great Scrum Master is aware of the different phases a team will go through when working as a team. He/she understands Tuckman’s different stages of team development: forming, storming, norming, performing and adjourning.
• Understands principles are more important than practices. Without a solid, supported understanding of the agile principles, every implemented practice is basically useless.
• Recognizes and acts on team conflict. A great Scrum Master has read the book ‘The 5 Dysfunctions of a Team’ by Patrick Lencioni. He/she therefore recognises team conflict in an early stage, can apply different activities to resolve it, and even better, he/she knows how to prevent conflict.
• Dares to be disruptive. A great Scrum Master understands some changes will only occur by being disruptive. He/she knows when it’s necessary and is capable to be disruptive enough to enforce a change, but without causing irreparable damage.
• Is both dispensable and wanted. A great Scrum Master has supported the growth of teams in such a manner they don’t need him/her anymore on daily basis. But due to his/her proven contribution he/she will get asked for advice frequently.
• Let the team fail (occasionally). A great Scrum Master knows when to prevent the team from failing but also understands when he/she should not prevent it. The lessons learned after a mistake might be more valuable than some good advice beforehand.
• Encourages ownership. A great Scrum Master encourages and coaches the team to take ownership of their process, task wall and environment.
• Has read… A great Scrum Master has read all the stuff produced by e.g. Geoff Watts, Lyssa Adkins, Tobias Mayer, Henrik Kniberg and Gunther Verheyen. 
• Has studied… A great Scrum Master has studied the Trello board that Growing Agile has published. The Shu-Ha-Ri levels offer a very useful STRUCTURE to a knowledge base for every Scrum Master.
• Is RE-TRAINED. A great Scrum Master recognizes himself in the acronym made up by Geoff Watts, RE-TRAINED: 
  • Resourceful: is creative in REMOVING impediments
  • Enabling: is passionate about helping others
  • Tactful: is diplomacy personified
  • Respected: has a reputation for integrity
  • Alternative: is prepared to promote a counter-culture
  • Inspiring: generates enthusiasm and energy in others
  • Nurturing: enjoys helping teams and individuals develop and grow
  • Empathic: is sensitive to those around them
  • Disruptive: breaks the STATUS quo, help create a new way of working
• Has faith in self-organization. A great Scrum Master understands the power of a self-organizing team.  Attributes of self-organizing teams are that employees reduce their dependency on management and increase ownership of the work. 
• Values rhythm. A great Scrum Master understands the value of a steady Sprint rhythm and does everything to create and maintain it. The Sprint rhythm should become the team’s heartbeat, which doesn’t cost any energy. Everyone knows the date, time and purpose of every Scrum event. 
• Knows the power of silence. A great Scrum Master knows how to truly listen and is comfortable with silence. He/she is aware of the three levels of listening and knows how to use them.
• Observes. A great Scrum Master observes his team with their daily activities. He/she does not have an active role within every session; for example, the daily Scrum is done by the team itself.
• Share experiences. Great Scrum Masters share experiences with peers. This might be within the organisation, but also seminars and conferences are a great way to share experiences and gather knowledge. 
• Has a backpack full of different retrospective formats. A great Scrum Master can apply lots of different retrospective formats. This ensures the retrospective will be a fun and useful event for the team. He knows what format is most suitable given the team’s situation.
• Can coach professionally. A great Scrum Master understands the power of professional coaching and has mastered this area of study. Books like Coaching Agile Teams and Co-Active Coaching don’t have any secrets for him/her. He/she knows how to guide without prescribing. 
• Has influence at an organizational level. A great Scrum Master knows how to motivate and influence at tactical and strategic levels.  Some of the most difficult impediments a team will face occur at these levels, therefore it’s important a Scrum Master knows how to act at the different levels within an organization.
• Prevent impediments. A great Scrum Master not only resolves impediments, but he also prevents them. 
• Isn’t noticed. A great Scrum Master isn’t always actively present. He/she doesn’t disturb the team unnecessary and supports the team in getting into the desired ‘flow’. But when the team needs him/her, he/she is always directly available.
• Forms a great duo with the Product Owner. A great Scrum Master has an outstanding partnership with the Product Owner. Although their interest are different, the Product Owner ‘pushes’ the team, the Scrum Master protects the team. 
• Allows leadership to thrive. A great Scrum Master allows leadership within the team to thrive and sees this as a success of their coaching style. They believe in the motto “leadership isn’t just a title, it’s an attitude”; it’s an attitude everyone in the team can apply.
• Is familiar with gamification. A great Scrum Master is able to use the concepts of game thinking and game mechanics to engage users in solving problems and increase users’ contribution.
• Understands there is more than just Scrum. A great Scrum Master is also competent with XP, Kanban, and Lean. He/she knows the strengths, weaknesses, opportunities, and risks of every method/framework/principle and how & when to use them. 
• Leads by example. A great Scrum Master is someone that team members want to follow. He/she does this by inspiring them to unleash their inner potential and showing them the desired behavior
• Is a born facilitator. A great Scrum Master has FACILITATION as his/her second nature.

The following are misinterpretations or breaking of the Agile Principles and suggested ways to fix the problem(s):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
   Some people focus on the ‘happy customer’ aspect of this Principle and will do whatever the customer asks.  This may make the customer happy in the short-term but the real value to the customer is delivering valuable increments of the product as early and continuously as possible.
   The fix – ensure the development team and customer agree on a regular Sprint and Release Schedule and ensure that they keep to it.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
   Some Agile teams understand the word "welcome" here as permission to forget about any requirements management at all. What is the easiest way to welcome change? Obviously, just get rid of any required documents!  However, this Principle does not mean abandoning any requirements management process.
   The fix – Ensure that the Product Owner maintains an ordered Product Backlog and that all change requests are handled by the Product Owner; the PO will decide if the change is justified and if it is whether the request is important enough to interrupt the current Sprint or whether it is placed on the Product Backlog in the appropriate business value position.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
   There may be some Development Team members that think this Principle applies at the Development Team level but does not apply to themselves individually.  It is difficult to imagine how these people think that the team will deliver without their individual contribution!
   The fix – Ensure that all Development Team members attend Release and Sprint Planning workshops and contribute effectively.  Additionally, ensure that all Development Team members attend the daily Scrum; it will soon become obvious if an individual’s progress on their chosen activities is less than ‘optimal’.
   The Scrum Master should engage any ‘miscreant’ Development Team member in individual mentoring to discover what the underlying problem is that is causing the problem and help the person to improve.
4. Business people and developers must work together daily throughout the project
   Working together doesn't mean working without clearly defined rules and processes. Some teams interpret this Principle as the legalization of chaos; they think that, since we work together, we do not need to define roles, we should not document requirements and we should not care about responsibilities.
   This is clearly nonsense; Agile requires that all the responsibilities necessary for successful product development must be identified and an individual or group of individuals take on one or more of those responsibilities.
   The fix – As a Scrum Master, for new Scrum Teams, ensure that a workshop is held with the Scrum Team and key stakeholders to define all the necessary responsibilities and ensure that all the responsibilities have been accepted by one or more people appropriately.
   Do not allow individuals to ‘quote’ their named role job specification in an attempt to avoid responsibilities; if they have the knowledge and capacity to fulfill a responsibility outside of their job specification, then they could accept that responsibility.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done
   It may be difficult for some ‘managers’ and ‘supervisors’ in the early stages of an Agile transition to ‘let go of the reins’; they are used to assigning low-level tasks to individuals and monitoring their work closely; their implies a lack of trust on their part in the ability of individuals and teams.  Agile teams should be self-organising and self-managing.
   The fix – As a Scrum Master, you must closely monitor the activities of ‘managers’ and ‘supervisors’ and if these activities are disruptive to the Development Team, then you must mentor the individual ‘miscreants’ to explain the Agile philosophy and Principles to them how their ‘interruptions’ are causing delays in development progress.
6. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation
   Face to face does not necessarily mean that all people contributing to the conversation being in the same room; some people believe it does and use this to avoid Agile when all people cannot be in the same room.
   However, technology has moved on since the Agile Principles were written; today, communicating by video-conference and desktop sharing facilities is commonplace.
   Video-conferencing is preferred over teleconferencing because with the latter, you lose the ability to observe ‘body-language’, an important part of any communication.
   The fix – As a Scrum Master, if communication with remote people is needed, whether within the Development Team or with stakeholders, encourage the use of video-conferencing at a time that is suitable to all the people in different time-zones.
7. Working software is the primary measure of progress
   This Principle states that working software is the primary measure of progress; it is not the only METRIC we can use to analyze product development.
   The Development Team measure and use their Velocity to help them plan; the business (product Owner) measures the benefit achieved from released increments.
   The fix – As a Scrum Master, you need to ensure that the Development Team and Product Owner agree the metrics that are to be used.  You must help to ensure that the metrics are measurable, relevant and are of value.
   You need to make sure that collecting any metric may have the effect of changing peoples’ behaviour; for example, if the number of lines of CODE per day was to be measured, developers may use verbose coding practices thus reducing progress and technical quality.
   The focus of any metric chosen must be its contribution toward the overall business value accruable from the product increments being delivered.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
   This Principle focuses on the wellbeing of all involved with product development but it must not be forgotten that the prime focus of product development is to deliver value to the ‘customer’; the Development Team cannot just keep working at a comfortable pace if they are not meeting the ‘value deadlines’ set by the ‘customer.
   The fix – As the Scrum Master, you need to ensure that the Development team estimate the Product Backlog Items and agree with the Product Owner what is possible in a fixed time and what is included in the Product Backlog MVP; ensure that the Product Owner is aware of his/her responsibility to measure the rate of delivery of business benefit.
9. Continuous attention to technical excellence and good design enhances agility
   This Principle means that there must be technical ‘rules’ in place that must be checked for in each developed requirement source code before it can be considered “Done” and allowed to be reviewed by stakeholders.  If these rules are not in place or they are not checked for, then the quality level will decrease resulting in an unhappy ‘customer’ and reduced progress as required REWORK is done.
   The fix – As the Scrum Master, encourage the Development Team, Product Owner and technical advisors to agree what the technical and design quality criteria are and how they will be checked for; the agreement forms the “Definition of Done” (DoD) that each requirement and increment will be checked against before it is reviewed by stakeholders.
10. Simplicity--the art of maximizing the amount of work not done--is essential
    To some developers, it is tempting to ‘future proof’ their work, adding functionality that may be or known to be needed later.
    This results in slowed progress and potential work when the perceived later need does not transpire.
    The fix – Ensure that there are some DoD criteria that check for future-proofing in the required source code.  This will encourage developers to:
    ‘Only do today what is essential to do today’
11. The best architectures, requirements, and designs emerge from self-organizing teams
    We say that the Development Team should be self-organising for the work that they do during Sprints but they are subject to constraints such as:
    • The overall technical architecture to work within; set by corporate tech architects.  The Development Team can ASK for amendments to the technical architecture but they have no control over it.
    • The requirements – Requirements are the Product Owner’s responsibility; the Development Team can suggest changes to the Product Backlog but they only have control of how the agreed requirements are implanted.
    • The design – There may be corporate design standards in place; again, the Development Team can suggest design changes but only have control over how the agreed designs are implemented.
      This Principle not just about the Development Team; the self-organizing concept applies to the wider group of business and technical stakeholders that must work closely together so that the product can provide the best business value.
      The fix – As the Scrum Master, you must analyze any constraints that the Development Team have to work with and ensure that adequate processes are in place whereby requested changes are speedily analyzed and accepted or not.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
    This Principle is embodied in the Scrum ‘Inspect and Adapt’ Pillar and is enacted through the Sprint Retrospective event.
    The Sprint Retrospective is not just about discussing what is wrong but also what is good and maybe the team should do more of.
    At the start of an Agile Transformation, the team may ‘find’ many things that are ‘wrong’; the long list may be seen by some to be time wasting and others as demotivating; ‘how are we going to address all these problems?’.
    Because of this, many teams give up on the Retrospective!
    The fix – The discovery of good and bad things during a Retrospective should be time-boxed to maybe 15 minutes when the major points will be discovered.  There are many Retrospective Games that can be played by the team members to make the discovery more enjoyable.
    An important part of the Retrospective is that the team prioritize the issues and plan how to resolve the top 1 or 2 issues in the coming Sprint.
    Progress on issue resolution can be done during the daily Sprint and the overall success of the improvement plans checked at the start of the NEXT Sprint retrospective.

Not necessarily. It is preferable to conduct it at the same time and the same place to reduce the complexity of MEETING OVERHEADS. UNLESS the Product Owner and Scrum Master are also part of the Development team it is not required for Daily Scrum. Daily Scrum is for the Development Team. The Daily Scrum is not PLANNED as a status report or management reporting mechanism. Performing Daily Scrum highlights liability and commitment in the development team.

The development team needs to facilitate. The development team is RESPONSIBLE for performing development work and meeting the Sprint Goal. If they have any ISSUES within their INFLUENCE to resolve, they are responsible to solve it. Scrum Master is responsible for impediments that are OUTSIDE the Development Team’s influence.

No. The entire team COLLABORATES with stakeholders during the product review. Scrum MASTER can also work with stakeholders to help them understand Scrum. Stakeholders communicate with Product owner with respect to Product Planning, its progress, and Product backlog changes. Good communication helps PROJECT stakeholders engaged and informed and keeps the scrum team FOCUSED on finishing the ACCEPTED work for the sprint.

You should gladly VOLUNTEER because being a Scrum MASTER in an ORGANIZATION also involves RESPONSIBILITIES to COACH the organization.

The SCRUM Master should let the team decide the FORMAT of Product Backlog items. The product owner brings forward the main OBJECTIVE that should be achieved in the sprint and the PBIS that would help to attain these objectives. The development team selects the PBIs that will help to achieve the sprint GOAL based on the product owner input and creates the plan for delivering the PBIs. The scrum master ensures that the scrum rules are followed appropriately. There is no need for a scrum master to conduct events, but instead to facilitate as required. 

In some PROJECTS, a development team member ACTS as a scrum master as there is no rule set up officially that a scrum master cannot be a developer. Definitely, it is hard to perform 2 roles at one time, however, it is definitely possible. A development team member playing the scrum master role depends on the team, team members skills and INTERNAL CHOICE of manager or team. Ultimately, everything is possible in agile-scrum projects.

By facilitating their decisions and removing impediments. Scrum MASTER does not manage the Development Team. It is the RESPONSIBILITY of the Development Team to manage its own EFFORTS. However, the Scrum Master helps them by facilitating their decisions and removing impediments and PROTECTING them from the EXTERNAL distractions.

YES. The Scrum Master position is the MANAGEMENT level position, but it is not a MANAGER position. Scrum Master does not manage the Scrum TEAM or even the Development Team but manages the Scrum process. If the Scrum Master is not at the management position, he or she may not have the INFLUENCE to remove the impediments.

The Scrum Master. It’s the responsibility of the Scrum Master to create a supporting understanding of Scrum in the whole organization. The Scrum Master is responsible for ensuring the team is ADHERING to the AGILE values and PRINCIPLES. The Scrum Master is the team facilitator. Along with that, the SM is responsible for clearing the obstacles, protecting the team from external interruptions and distractions that HINDER the project goal.

Yes. The Scrum Master is one of the roles from the Scrum TEAM which is responsible for ensuring the team is adhering to the Agile values and principles. The Scrum Master is the team facilitator. Along with that, the SM is responsible for CLEARING the OBSTACLES, protecting the team from EXTERNAL interruptions and distractions that hinder the PROJECT goal.

The focus of the TEAM should be on delivering VALUE to the customer. It is not only the responsibility of the team but also it is important from the organization perspective. Each story is built on the concept of priority and value added to the customer. If the team is able to bring value through frequent deliveries and product increment, then the client will be HAPPY. The client satisfaction can also be one of the metrics to measure, if the client is able to realize value, it will be worth their money.

Another one can be, focus on minimizing the technical debt, once the product development starts, it is important to do the maintenance work from time to time to ensure the performance of the product, no one wants a dead code in the system. Bugs, refactoring, and research also requires regular attention to avoid building-up technical debt. Any metrics which cannot relate to the value delivered should be avoided in such scenarios as they portray a different picture, e.g, though velocity variance is a good metric to track if I relate to value DELIVERY it won’t work well.

Hence, the focus should always be on value delivery, and it should be the prime goal.

One of the ADVANTAGES of working in Agile is the clear backlog visibility at least for three sprints. If the product OWNER is adding up the ITEMS in the backlog, then it might be he or she is getting ideas and they are just parking aside on the backlog. That doesn’t mean that the team has to work on all the ideas. A product backlog can have a list of items to be accomplished, but the team will only focus on the high priority items which can add value to the client.

Also, here, the role of a scrum master can come handy, this role can help the product owner understand how to arrange the backlog, and how to create items that can be consumed by the teams. The scrum master can explain different prioritization techniques that can be used for keeping the backlog sorted. But the scrum team is not expected to pull up everything that is on the backlog. One of the roles of the Scrum Master is to coach the product owner on how they can best converse their intent to the DEVELOPMENT Team. There are many techniques to accomplish this, such as product visioning, product road mapping or release PLANNING.

The product backlog contains a list of items to be worked upon by the team but it is important to check if the items are in a ready state to be picked up in a sprint. The Team must be able to determine what needs to be done and the amount of work required to complete the User STORY or PBI. The Definition of Ready can differ from product to product or from team to team. It is a working agreement between the team and the Product Owner on what readiness means. LET’s LOOK at some of the parameters that can go in defining the Ready state:

Definition of Ready for a User Story

1. The PBI is in “Approved”, or equivalent, state for the team to pick it up for development
2. User Story dependencies identified
3. Acceptance criteria exist and are understood by the team
4. Acceptance criteria have sufficient details on the features to be developed and TESTED by the team
5. Performance criteria have been provided, where appropriate, and are understood by the team
6. The PBI has been written in the
7. Actor->Action->Outcome format
8. UX wireframes exist, where appropriate, and are understood by the team
9. Performance criteria identified, where appropriate
10. Team has a GOOD idea of what it will mean to Demo the User Story

The team’s PERFORMANCE is not just related to a single EVENT or a reason but there can be different scenarios that might be building up that situation. A good scrum master has to identify those patterns and look out for ways to minimize it. Let’s look at a few of the situations that might lead up to lowering the team’s performance:

• Planned Leaves or Holidays – The sprint commitment is directly proportional to the total available capacity of the team. If there are leaves or holidays, the commitment will go less and hence lowering the velocity.
• Legacy product – In case the code has been written long back with no DOCUMENTATION, the new members struggle to figure out things.
• New hire – Onboarding a new associate will impact the sprint commitments as the member is new and needs time to be brought to speed.
• Resignation – If the team members are leaving, it might take some time to fill up the gap.
• Experience – If the team comprises of experienced team members along with new one, then the level of SENIORITY might hinder the team formation.

There can be many reasons, but the scrum master should keep their eyes open for any such patterns and try to help the teams get back to track through coaching and adoption of best practices.

Every organization opting for Agile creates a model to assess the maturity at different levels. It helps them stay focused and goal-oriented. It is an ASSESSMENT of an organization’s suitability for agile practices, PROVIDING an idea of the necessary steps for an organization that decided to become a learning organization. The METRIC is based on the initial collection of data as to what the current situation is and what is the desired level. Hence, the parameters involving the assessment can be different for different organizations.

In our case, the focus was on:

• Ability to accept change
• Team communication
• Team Location
• Delivery Regularity
• Planning Methodology
• Testing
• Business Value Focus
• Technical Excellence

Each of the pointers mentioned had sub-details to analyze and assign an appropriate number. The assessment was done on a regular interval to check if the teams are REACHING the milestones set in agreement with the management (agile focused). It also helps in identifying areas which need immediate attention. The team can SWARM together to improve that item.

Though Scrum mentions the Scrum Master role as the person enforcing the process, it is important to understand what exactly does the enforcement mean and what its boundaries are.

Enforcement does NOT mean forcing the team to follow the process, but it implies putting in practice the core ENTITIES of the Scrum to help the teams be successful. The Scrum Master is the facilitator HELPING the teams reach their goal. During facilitation, the Scrum Master will use Scrum practices and would encourage the team to follow the scrum values.

Again, it is important to mark that we are talking about encouragement and not forcing. It is not a role similar to the project MANAGER but this role will help the teams to BRING their blockers to closure, it will be a collaborative effort and not a directive one. From time to time, the scrum master will try to show the benefits of adopting the processes and help the team acquire an understanding on the scrum processes which is like showing the right path but it is up to the team if they WANT to walk through it. The scrum master will also be acting as a coach for the team to help with outshine in the agile journey and be successful.

To make the retrospective effective, the team should identify the action items. This gives a platform to the team to start a conversation, but only identifying will not serve the purpose. The action items should be targeted for closure and scrum master should take steps in realizing this goal. For every action item, there should be an owner, TEAMS should refrain from assigning multiple owners to a single item as the idea of ownership dilutes. The scrum master should manage the REPOSITORY of action items on a tool or an EXCEL which is accessible to all the team members. Having a backlog of action items also helps as then the team can actually prioritize.

In the retrospective meeting, the team should go through the items from the last retrospective and talk about its status, in that way everyone can keep track of where they are and what more is required to ACHIEVE the goal of closure. Few organizations use retrospective tracker where the action items are categorized into – priority, ownership, status, description, identified on, type. Working on the actions items gives the team a boost that they are moving forward towards improvement and also it enhances the sense of ownership.

When the Scrum teams follow the same pattern of the retrospective sprint by sprint, it does induce weariness among the teams. The Scrum Master needs to be CREATIVE enough to try out different patterns, sometimes CHANGING the location also works. Anything that HAPPENS regularly with the same format tends to create an uninteresting environment in the meetings.

As discussed in the earlier question, the scrum master can use different types of retrospectives to create a fun introspecting atmosphere. Some of the teams opt to go out for lunch and have a discussion over there, it not only helps to collaborate but also provides a safe environment to DISCUSS. Or you can use a different room. While creating a conducive environment to reduce the boredom, the Scrum Master has to make sure that the essence of a retrospective is not lost. The intent should be the same even when you are using different patterns.

As mentioned in the earlier question, sprint retrospective is an opportunity to inspect and adapt the process. Thus, checking the team’s health at this meeting can be a good opportunity. The team should together this time look at the areas of improvement and talk about the overall health.

The Scrum Master can facilitate the health check through various tools, simple can be using a scale from 1-5 where 1 STANDS for awful and 5 for extraordinary. They can even use the TeamHealth Retrospective which is a powerful deep-dive strategic retrospective tool that FOCUSES on the top areas that affect team performance and health.

To check the team health, the team can COME up with the parameters to check on the health – Culture, Technical Practices, Quality, Backlog Visibility, and Team Collaboration. The team can have its own customized parameters and against those parameters, there will be some points to validate that parameter. The team, after discussion, gives a point on the scale of 1-10 to that parameter. The same goes for all the parameters. Once this activity is done, the tool will automatically generate a SPIDER chart showing the areas that need improvement. The Scrum Master can coach and suggest the team on how to REACH the 5 in the spider!

The meaning of ‘Kanban’ is a visual board, where ‘kan’ means visual and ‘ban’ means board. In Scrum, the sprint board works in Kanban manner. Let me pull up a draft board:

It is comprised of vertical swimlanes where each lane stands for a phase in the sprint execution. Horizontally, it contains the sprint items. Each vertical swimlane can be customized as per the PRODUCT or project need. USUALLY, it has – Backlog, To Do, In-Progress, Done and Accepted as the header. Once the team has started working on an item, it will start flowing from one phase to ANOTHER. If the item is blocked due to an impediment, then it will SIT in that vertical till the time is resolved.

The scrum master has to help the team in a smooth flow of sprint items through continuous collaboration, discussion, and focused approach.

The additional information to cover-up the Kanban can be:

• Sprint timeline – Start date and the end date
• Sprint Cadence - Pulse or rhythmical flow of scrum events
• Definition of Ready – Entry criteria for the user stories
• Definition of Done – Exit criteria for the user stories

You can even mention the metrics around the Kanban board. The Kanban board serves as an information radiator for the team and outside the team (stakeholders + management).

The daily standup meeting in agile remains the same, that is, 15 minutes, where the team meets, talks about the three questions. Any further discussion will be a part of the SIDEBAR, that’s it! “For teams that share work between TIME zones, stand-up is a great time to pass the baton as the team which is coming online can pick up right where the other team had left off. And holding stand-up via video conference makes it easy to ask questions and get up to speed so everyone is off and running as soon as the meeting is done.” - Atlassian

This applies to all the Agile/Scrum teams whether they are co-located or distributed, the scrum events remain the same. With distributed teams, there is just a small difference – they use video conferencing for sprint BOARD sharing (if no online TOOL is being used). But if the teams are using tools like Version 1 or Rally or any other tool, they can simply use a dial-in number to connect with each other. There are multiple PLATFORMS like Skype which can be used to bring together the teams. Here, the Scrum Master can come up with creative ways of working with distributed teams, like - coordinating across time zones, building a relationship when everybody is not in the same office, working together among different development cultures.

The daily stand-up meeting helps the team to echo on the development of the team's COMMITMENT towards the sprint goal. Hence, all agile teams should meet on a regular interval so that everyone is talking the same language. The way of executing the standup can DIFFER according to the size and experience level. Lets’ take up some scenarios:

• Small & Experienced – If the size is small with experienced members, the team can meet up over a quick break, they can EVEN opt for a casual meeting.
• Small & Less Experienced – Even though the size is small, the Scrum Master should prefer going through a formal standup as the team needs to understand the progress, they might need help with technicalities or business functionality, they also need to realize the values, principles and the discipline in the process.
• Large Teams – Opting a casual approach might prove difficult with large teams, as for large teams formal meeting is required to provide guidance and clarity.
• DISTRIBUTED Teams – Your team is considered co-located when the developers and the primary stakeholders are all situated in the same workroom. Otherwise, your team is either geographically distributed or dispersed in some MANNER. In the case of distributed teams, since there is a constraint of location, the teams can use the ‘dial-in’ and conduct the daily scrum in an organized manner.

The entry criteria for any STORY in a sprint relies on Definition of Ready which involves creating clear criteria that a user story must meet before being committed into an upcoming iteration. In our SCENARIO, the user story lacks final designs which clearly indicates that it is NOT ready to be picked up for the commitment. Also, in this scenario, the product owner agrees and pushes the team to commit. As per Agile, it is a wrong practice, BUT, it also depends on the team’s circumstances. If the past experience says that the design team has been DELIVERING as promised on the timelines, or if the story is of high value to the client, in such cases the team can go ahead with the exception and commit the story.

However, this should not be made a regular practice as it would be a compromise with the principles and with the core essence of Scrum. The Scrum Master should LOOK for such anti-patterns and help the team understand the importance of Definition of Ready.

It all depends on the team’s situation to go ahead with the exception or reject the same. Accepting stories which do not meet the ready definition increases the risk of completion and even impacts the teams’ efficiency.

The following facilitator activities are required when preparing for a workshop:

• Identify the Workshop Owner – Each workshop must have an owner; the person who needs the group decisions.  For example, for a requirements gathering workshop, the owner would most likely be the Product Owner.
• Establish the Workshop Objectives – You can treat a workshop like a mini product development; the Vision is the overall reason for the workshop; the Objectives are the first decomposition of the Vision.  For example:
  • The Vision: To decide which products to promote
  • The Objectives:
    • Decide the products in scope
    • Evaluate the relative value of the products
    • Establish a prioritized list of products to promote
• Establish the Participants – The Workshop Owner should give a list of required workshop participants and/or direct the facilitator to a person who can provide that information
• Establish by when the workshop must be run – All decisions are time SENSITIVE.  It may be that some proposed participants may not be available at specific times.  The date and time of the workshop must be chosen to be within the cut-off date and to maximize the number of proposed participants
• Establish the type of workshop to be run – Workshops can be run as participants sitting around a horseshoe-shaped table to an ‘Open Space’ where participants are free to roam a room with separate areas for DISCUSSION on specific topics.
• Arrange the workshop venue – A workshop venue must be chosen and booked to suit the number of proposed participants and the workshop type
• Establish any pre-workshop participant reading materials – It may be useful for proposed participants to have some information pertinent to the workshop before the workshop begins.  Although you, as a facilitator, will give them access to these materials, do not expect every participant to have READ them!
• INVITE the participants to the workshop – Send invitations to the proposed participants with the following details:
  • The reason for the workshop
  • The Workshop Owner
  • The workshop Objectives
  • The date, time and venue for the workshop
  • The proposed participants; this may be the distribution list on the email; it gives proposed participants to suggest other participants and/or to suggest replacements for themselves
• Arrange for refreshments to be available
• Prepare the workshop space
• POINT of Process

If a participant feels that the group discussion is not following the correct procedure or a discussion has gotten off topic, they may make this hand gesture and say out loud “Point of Process.” 

The Stack Keeper allows them to speak before the next person at the top of the stack. They must then say how they think the discussion has gotten off topic or is not following procedure. 

Example 1: “I’m not sure why we’re talking about shifts when the agenda says we’re supposed to be talking about salaries.”
Example 2: “There’s a proposal on the table, and I think we should resolve that before we move on to anything else.”

Although a Scrum Master is SAID to facilitate the team to produce the best results, workshop facilitation is sometimes a different matter.

A workshop facilitator must be independent of the TOPICS being discussed and should not CONTRIBUTE facts or opinions to the conversation.

In most general product development workshops, if he/she has the SKILLS, the Scrum Master may facilitate the workshop.

However, if the workshop is to discuss something like modifying the Scrum process, the Scrum Master does have important things to contribute and should not facilitate that workshop.

The role of the Scrum Master majorly includes the facilitation. The SM facilitates the Daily Scrum for the development team to DISCUSS the daily tasks and to increase team collaboration. The Scrum Master also ENSURES that the team is strictly adhering to the Daily Scrum meeting rule that the meeting should be time-boxed to 15 MINUTES only.

By facilitating Development Team DECISIONS and by removing impediments that hinder the Development Team. A Scrum Master is a servant-leader for the Development Team. Facilitation and removing impediments serves a team in ACHIEVING the best productivity possible. The Scrum Master within the Scrum Team FACILITATES the development of working software and help the development team in DELIVERING the Product Increment. The Scrum Master does EVERYTHING possible to help the development team to work at their highest level.

A Scrum Master does not have to be there; he or she only has to ensure the DEVELOPMENT Team has a Daily Scrum. The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. ALTHOUGH the Scrum Master or Product Owner can attend this meeting to facilitate the Daily Scrum, this is certainly not required by Scrum. The Development Team members synchronize their WORK, monitor their PROGRESS toward the Sprint Goal and if required they adapt the Sprint Backlog and the plan for the NEXT 24 hours during the Daily Scrum.

Peer team member. The SPRINT Retrospective PROVIDES an opportunity to inspect and adapt the progress for improvements. The Scrum MASTER plays the role of a facilitator for his/her team. In the Scrum framework, the teams are self-organized and open to MAKING changes very quickly wherever needed.

The Scrum Master arranges the Scrum MEETING for the Development TEAM. The Development team is the main player in the meeting.  But, the Scrum Master GUIDES the Development Team to keep the Daily Scrum WITHIN the 15-minute time-box. The Scrum Master enforces the rule that only the Development Team members PARTICIPATE in the Daily Scrum.

A user story represents a small piece of business value that a team can deliver in a sprint. Though traditional requirements (like use cases) try to be as DETAILED as possible, a user story is defined incrementally in THREE STAGES:

• Who are we building it for, who the user is? — As a <type of user>
• What are we building, what is the intention? — I want <some goal or objective >
• Why are we building it, what value it brings for the user.? — So that <benefit, value>

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

• Independent - Can the story stand-alone by itself?
• Negotiable - Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
• Valuable - Users or customers get some value from the story.
• Estimable - The team must be able to use them for planning.
• Small - LARGE stories are harder to estimate and PLAN. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
• Testable - Can this story be tested and verified?

The Product Owner is invested to conclude the value that the USER story will deliver, enabling him or her to set the backlog as per the highest priority. When a user story is created, it carries some value (we have also LEARNED about it in the INVEST model where V STANDS for Value). When the sprint is being planned, the team pulls up the highest priority item from the pile for commitment. If the team members are picking up tasks as per their comfort, the scrum master has to come in picture and coach the team. Even the product owner might pick up stories which are not ADDING value to the customers.

Hence, the story time or the sprint PLANNING meeting should be addressed in the true sense, the scrum master should facilitate these meetings in a way that they stick to the intent of the meeting and come out with the valid outcomes. Both the team and the product owner has to focus on value delivery rather than ease of work. If the teams are involved early during the product discussion, these types of challenges can be minimized.

As a Scrum Master, I will not accept this process as it is its sugar coating WATERFALL in the name of AGILE. Just converting the requirements into TICKETS will not suffice for the entry criteria of the user stories. The requirements should be finely broken down into finer pieces so that it can be consumed in sprint time. The conversion of stakeholder requirement into tickets should also follow the best practices in the industry like INVEST, 3Cs, etc. to help teams gain confidence into what is to be built.The focus should always be on delivering value to the customers, which requires keeping a health prioritized backlog. The organization adopting Agile use tools like Rally, Version 1, etc. to manage the PRODUCT backlog and sprint backlog. Hence the requirements should be entered in the tools for the teams to pick.

Moreover, the scrum TEAM should be involved early in the product discovery process so that all the parties involved have a shared understanding of what is to be built. This also helps in curating the requirements which are feasible and have pre-identified risks and challenges. Finally, the Scrum Master should help the teams to be agile and not just allow anti-patterns to grow.

As the saying goes, “One SIZE doesn’t fit all”. Same goes for Agile. All projects and products might or might not fit into the agile arena. In our case, it is working and we are actually reaping the benefits. Let me list out some areas where we SEE the difference:

• Faster Time to Market - The idea of two-week delivery cycles and quarterly RELEASE cadences helped in quicker deliveries.
• Feedback from real customers – Frequent collaboration with the clients helped the teams in BUILDING the right product rather than delivering at the end with surprises!
• Prompt risk detection - By delivering early and GETTING feedback, we reduce the risk of building the wrong product. By focusing on architectural risk in the early sprints, we reduce the risk that we won’t have a solution that can be built in time, at least the team knows it early.
• Improved Quality Stats – Quality is an integral part of the sprint in terms of code coverage, unit tests, peer reviews, etc.
• Predictability – With the teams trying to stabilize the velocity, we could easily predict the capacity for the upcoming release.

Every Agile journey is different, hence their experience. Thus, it is important to identify the success factors to promote excellence.

Retrospectives don't finish when they're concluded. In fact, the toughest part has now been initiated: Following-up on your retrospective action plan. In a retrospective, one of the outcomes is the action items which the teams have identified to make their process or work environment much better (retrospective can touch base at different levels). If the action items identified during the last retrospective is not worked UPON or gets LOST during the course of the sprint, the team will start refraining from coming up with the points as they will not see any closure on the items. Hence, the SCRUM Master should PRESENT the action items from the last retrospective and discuss the status of progress.

This gives a sense of satisfaction to the team that they are getting heard and the items are being tracked to closure. There are several ways of following up, for example,

RUNNING the activity:

1.   Open the list of action items (and their respective owners)
2.   Update the status for each item on the list.
3.  Add newly identified items

Each team can have a different tool for tracking their action items. Some examples: post-it on the team wall, a shared excel document, Trello, etc.

The RETROSPECTIVE format provided by Scrum Guide contains three items:

• What went well?
• What didn’t?
• Action Items to improve

This is the usual format that is being used by the Scrum teams. But after a while, it gets monotonous to use the same. And as each team is different, the same formula MIGHT not go well with all. There are many different retrospective ideas out in the AGILE world, including distinctions and trimmings on the rudimentary questions and creative facilitation techniques.  Scrum Masters should develop a toolkit of retrospective techniques that they can use and adapt to their teams. LET’s look at a few:

• Sail Boat - The idea is to draw a speedboat on a flip chart and ask the team, “If our team is this speedboat, what anchors are holding us back and KEEPING us from getting faster/better?” Then the team collects all their ideas on Post-Its, puts them below the boat and draws a line from the boat to the anchor.
• Speed Car - This is a simple activity for helping the team to identify things that make them move faster, and things that slow them down.

There are several other ideas as well, like:

• Liked, learned, lacked, longed for (4 L’s)
• Starfish (small, large)
• Stop, start, continue
• Mad, sad, glad

The sprint retrospective is an opportunity to inspect and adapt the process as it is a time to reflect on the process. It is needed that the full Scrum team attends. This includes all members of the development team (includes everyone who is designing, building, and testing the product), the Scrum Master, and the product owner. Since the Scrum GUIDE also states that the Scrum team = product owner + Scrum Master + development team, we can DEDUCE that (officially at least) the product owner is allowed to attend the retrospective. This is the ideal scenario. 

HOWEVER, SOMETIMES, the teams MIGHT not wish to include the product owner as it might hinder their discussion. If there is a lack of trust between the product owner and the development team, or there is a low level of safety so that speaking candidly isn’t comfortable, perhaps the product owner should not attend until the Scrum Master can help coach those involved towards creating a safer, more trusting environment. Anyone else outside of the immediate scrum team, and particularly managers of team members, should not be invited to participate.

One of the Agile Principles states “Business people and developers must work together daily THROUGHOUT the project”. The stakeholders can join the daily scrum meeting but they can be mute spectators till the time scrum is not complete. The Scrum Master should encourage the stakeholders to join the meeting by making them understand that it will be worth their time.

The goal of the Daily Scrum is to know whether or not they will reach the SPRINT Goal. If the stakeholders are joining the daily scrum, then they will get to know the updated picture of product development and can accordingly adjust their expectations. They get to know about the real issues that the team is facing, which helps both the parties. This event gives the opportunity to the development team to directly ask questions with the stakeholders. It not only promotes a platform for discussion but also provides early detection of risk for the stakeholders. But the Scrum Master should make sure that the INCLUSION of the stakeholders in the daily scrum is not converting the meeting into a status UPDATE. Although stakeholder presence is not mandatory, it doesn’t matter if they are there as a listener because it can facilitate the resolution of any IMPEDIMENTS.

As part of a Scrum Master role, one of the responsibilities entail around helping and coaching the Product Owner. It is really critical for the Scrum ROLES to understand their role and function accordingly. If the product owner is assigning the user stories/tasks, it is the job of a scrum master to make the product owner realize the meaning of self-organization.

In the Scrum Guide, a partial definition of self-organizing is given as Scrum Teams are self-organizing. Self-organizing teams choose how to accomplish their work, rather than being directed by others outside the team.” Self-governance is one of the utmost motivators there is for people doing creative and problem-solving types of work. Assigning tasks to people is an implicit claim that the product owner knows better than the team, this not only passes on the wrong notion but it also LOWERS the morale of the team and at the same TIME defies the scrum VALUES and Agile principle – “Point 5. Give them the environment and support they need, and trust them to get the job done.” And “Point 11. The best architectures, requirements, and designs emerge from self-organizing teams.”

Hence, the product owner is assigning work, the Scrum Master should intervene and help the Product Owner in understanding the true sense of working in a Scrum framework and refrain him/her to continue this practice.

When the sprint is being planned, the team commits the sprint items as PER the available capacity. To target the optimum execution, the team should ideally commit between 80% - 90% of the team’s total capacity, anything beyond that percentage will HINDER the team’s performance. Bugs, refactoring, and research requires consistent attention in ORDER to escape building-up technical debt.

Though the teams already have items to work on from the product owner, some of the teams set aside 25% of the capacity for this job. We also have a good practice which the teams can follow, 15-10-5 allocation of the SCRUM team’s capacity, which means, 15% of a team’s capacity to technical debt, 10% of a team’s capacity to defects, and 5% of a team’s capacity to exploratory work.If the team is able to follow these allocations, it will fulfill both the code quality and UPKEEP necessities of most software applications.

It is a good practice if followed sprint by sprint, but if for some reason the team is not able to do it in a particular sprint due to high priority delivery, it’s fine.

Anyone can write USER stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. – Mike Cohn

During the early product discussions, the team talks about the requirements and capture those in the form of user stories. As product backlog always live, never stays frozen. Hence, if SOMEONE feels there’s a missing requirement or something that can add value to the client, they can add it up as a user story in the backlog. There is no rule or guideline stating that only the product owner has to write the stories. People writing the story should understand what exactly it means and how to write it, as there is a set format.

Writing user stories also gives a sense of OWNERSHIP to the team members and they can connect easily if they are involved in the writing PROCESS. User stories are written all through Agile development. Typically a story-writing WORKSHOP is held near the start of the agile project. Each person on the team contributes with the objective of crafting a product backlog that completely calls out the functionality to be added over the course of the project.

Estimating in man-hours is ONE of the most prevalent methods for assessing teamwork. While man-hours are EASY to understand, there are a few big disadvantages to this method:

• Few tasks are hard to estimate precisely, e.g. the legacy work
• If one team member provides the estimate but another COMPLETES the task, the estimate becomes worthless.
• The time needed to complete a task will vary based on a developer’s level of experience.
• Teams usually misjudge impediments they might face and contemplate only the best-case state.

The advantages of estimating user stories in points can be – There is no correlation with the skills and experience of the estimator, STORY points do not depend on who is doing the story. As the story points are a MEASUREMENT of relative sizes, and the size of the story cannot be changed by external pressure, the team members can estimate more accurately. Story Points invites collaboration as team behavior becomes prominent over individuals. Using planning poker to estimate story points brings the team together.  It acts as a team building activity as teams share, constructively criticize each other, debate and have fun playing poker cards to come to a consensus on estimates.

Sprint planning is a collective effort including a Scrum Master, who facilitates the meeting, a Product Owner, who makes clear the specifics of the product BACKLOG items and their corresponding acceptance criteria, and the complete development team, who outline the work and effort necessary to MEET their sprint goal. The scrum master can help the team by:

• Time-boxing the activity
• Making the team stay FOCUSED on the intention of the meeting
• Facilitating and Resolving(if required) any deadlocks in the discussion
• Can help them to commit the RIGHT amount of work, as per their available capacity.
• To make sure that the team is invested and asking the right questions.

To accomplish this, the scrum master can help the team understand the definition of being ready and the process to create meaningful stories. ALSO, as discussed earlier in the questionnaire, it is important to get the team to participate in the early discovery process to make them understand the product. The stories should be created as a collaborative effort between the development team and the product owner, this creates a shared understanding of the common goal.

During the early phases of the product development LIFECYCLE, it really helps if the scrum team is made part of the DISCOVERY process. You should understand that AGILE talks about the early involvement of the teams with the stakeholders so that both parties are on the same PAGE in regard to the development. Let’s look at some of the advantages of early involvement:

• The development teams identify the technical challenges in implementation early in the process, hence, can help in reforming the requirements along with the customer.
• The team along with the product owner also start sharing a common understanding of what is to be built. Sometimes, the teams can help the product owner in identifying the requirements which might have been missed.
• They share a mutual understanding of what is to be built. It also helps the teams to stay committed and confident, they tend to build an ownership of their work and most importantly it boosts up the morale of the team.

To facilitate this, the scrum master can start involving the teams in early discussion of the product where the requirements are still at a high level. The team TOGETHER with the product owner can build up the product backlog.

Agile talks about CONTINUOUS interaction and collaboration between the scrum team. The team members should NOT wait until the next daily scrum to ask for help, in this way, they are introducing delays in the process which will impact the overall sprint goal. If there is an obstacle, it should be raised then and there. In a sprint PLANNING, the team commits the sprint items as per their capacity.

For example, I have 50 hours of committed work but due to some BLOCKER, I got stuck. Now, if I wait to talk about it the next day or next daily scrum, I am wasting my workable hours which could have been resolved by raising it then and there. The QUESTION also specifically calls out for the ‘experienced team members’ which means if the experienced members are resorting to waiting, then it sends the wrong message to other team members. Such behavior within the team also portrays hidden conflicts or team members hesitating to talk. The Scrum Master should help the team in understanding the importance of real-time discussions, and promote healthy dialogue between the scrum team. Even the Scrum Master can COME up with some team-building activities to make the team collaborate more efficiently.

For a SCRUM Master, it is important to understand the pulse of the team. If there’s a MEMBER in your team who takes the meetings as useless, it’s time to know why he/she is adopting such a behavior. The focus should be on the behavior rather than the individual, the Scrum Master should try to talk to the team member individually by asking open-ended questions to find out the reason for not attending the meeting. Certainly, there is a need to understand the cause of this behavior and try to explain the importance of the planning meeting (Scrum ceremonies).

In Scrum, each individual is important, it is like wheels of a truck, any wheel gets dealigned or malfunctioned, the complete VEHICLE suffers. Hence, the need to explain the impact of not having his presence in the planning meeting and its impact on the entire team arises. Even the team can start to feel this imbalance. If it is STILL not resolved, the Scrum Master can set up a meeting with his reporting manager to talk about the concern and look out for WAYS to help the team member and the team.