Definition of Done

This article discusses the Definition of Done in Scrum

In Agile development, where adaptability and continuous delivery are key, the Definition of Done (DoD) acts as a cornerstone. It’s more than a checklist — it’s a shared understanding of what “complete” means. This ensures transparency, quality, and consistent value delivery.

What is the Definition of Done?

The Scrum Guide defines the DoD as a formal description of the state of the Increment when it meets the quality measures required for the product. In simple terms, it’s a set of agreed-upon criteria that must be satisfied for a Product Backlog Item (PBI) to be considered “done.”

Sample Definition of Done for an E-commerce Website

Here’s a sample DoD for an e-commerce website. Each point can include specific details — for example, “Performance and Security Standards Met” might list page load time limits, vulnerability checks, and encryption criteria.

• Acceptance criteria met
• Performance and security standards met
• User experience (UX) and accessibility verified
• Documentation and code quality maintained
• Deployment readiness confirmed

Why is the Definition of Done Important?

The DoD drives success by:

• Ensuring Transparency: It provides a clear, shared understanding of what “done” means, eliminating ambiguity and fostering trust.
• Maintaining Quality: It sets high standards, reducing defects and rework.
• Boosting Predictability: A consistent DoD supports more accurate sprint planning and forecasting.
• Enabling Continuous Improvement: The DoD becomes a baseline for identifying improvements.
• Delivering Value: Each Increment is potentially releasable, ensuring value delivery.

Organizational Definition of Done: Minimum, Not Maximum

Many organizations create a company-wide DoD to promote consistency. However, this should define minimum standards — not maximum limits.

Rigid, overly detailed organizational DoDs can restrict teams and reduce flexibility. Instead, teams should build on the organizational baseline, adapting their DoD to fit their product’s unique needs. This balance preserves quality while empowering teams to respond to evolving requirements.

The organizational DoD should focus on essentials that apply to all products, like security scans and basic documentation guidelines.

Who drafts the Definition of Done?

The Scrum Team — including Developers, Product Owner, and Scrum Master — is responsible for the Increment and its quality. Together, they define and maintain the DoD.

• Product Owner: Ensures the DoD aligns with stakeholder expectations.
• Developers: Define the technical criteria needed to meet “done.”
• Scrum Master: Facilitates the process, ensuring the DoD is clear, realistic, and understood by everyone.

This collective responsibility ensures the DoD reflects the team’s combined expertise and remains achievable.

Why the Definition of Done Must Be Clear

Ambiguity causes misunderstandings, inconsistencies, and rework. A clear, precise DoD prevents this. We call such a clear and crisp DoD as a “Strong” DoD.

A Strong DoD:

• Uses SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound)
• Avoids jargon and unclear technical terms
• Is easily accessible to all team members
• Is reviewed and updated regularly

Clarity ensures everyone stays aligned, promoting consistency and minimizing errors.

How the Definition of Done Evolves

The DoD isn’t static — it evolves with changing technology, requirements, and team capabilities. As the team learns and grows, new criteria may emerge to enhance quality and efficiency.

Ways the DoD can evolve:

• Retrospectives: Regular reviews help identify areas for improvement.
• Stakeholder Feedback: External input reveals gaps or necessary adjustments.
• Technological Advancements: New tools may require updated criteria.
• Learning and Experimentation: Successful new practices should be integrated.
• Scaling: Organizational DoDs may need adjustments to support multiple teams.

By embracing continuous improvement, the Scrum Team keeps the DoD relevant and effective, supporting high-quality product delivery.

The Definition of Done is a foundation of Scrum. It ensures a shared understanding of quality and completeness. By creating a clear, evolving DoD, Scrum Teams enhance transparency, improve predictability, and deliver greater value to their stakeholders.

By WOA Author

The post Definition of Done appeared first on World Of Agile.

In the article before, we have discussed many metrics that can be used by the Product Owners or the Developers in order to help them generate value at a regular frequency and in a efficient as well as effective manner. However, one accountability that we have not yet discussed is the master of the scrum, our Scrum Master. Does this mean that Scrum Master does not have any metrics ? Or that the Scrum Masters performance can not be quanitified at all?

If that has to be true, then how will the Scrum Masters improve their own way of working and ensure more effective as well as efficient outcomes for the whole Scrum Team? 

In order to decide what metrics, the Scrum Master can track and use we need to consider the key accountabilities of Scrum Master as explained in the Scrum Guide. The Scrum Guide says, master is accountable to ensure that 

• The team continuously improves its effectiveness
• Developers are able to create high value increment that meet definition of done
• And the Scrum Team implements scrum the way it is defined.

Considering the about 3 asks from the Scrum Master, Scrum Master needs to track the trends in other metrics so that the Scrum Master can help Developers or the Product Owners to help improve their own ways of working.

Also, the Scrum Master is a coach for the Scrum Team and at such needs to ensure that the team is self-managed where the team is empowered, enabled and capable of taking decisions independently without excessive support from the Scrum Master. Scrum Master also ensures that the Scrum Team is implementing scrum the way defined in the guide and to do that scram master may track how the various Scrum Events and are the rules stated in the guide are being followed by the team not only in the words but also in the spirit that they are meant.

When considered in this perspective, it is the Scrum Master who is helping the Scrum Team and the rest of the organisation to create a metric framework that can act as a backbone which supports the Scrum Team to continually improve its way of working leading to better value delivered more frequently.

Below I have given some sample Metrics that can help the Scrum Master.

1. Number of times Scrum Master has to be the interface for the developers – with PO /With Organization
2. Team Independence
3. Over All team effectiveness – trends in other metrics
4. Metrics which are found useful by Scrum Team / Metrics which are found cumbersome

The post Agile Metrics and The Scrum Master appeared first on World Of Agile.

Within the Scrum Team the Product Owner and the Developers often have different focus and different perceptions on what do they mean by value or how to improve the effectiveness of their own work and that of the entire Scrum Team.

This means Developers and product on us need different set of metrics in order to be really effective and efficient.  A common anti pattern often seen in Scrum is to have a metrics framework that is generic and not tailored for the individual accountabilities. In my experience it is worthwhile to spend time and energy into deciding specific metrics for both these accountabilities.

Each team needs to define Metrics that help them inspect and adapt. Below I have given some metrics Product Owner as well as Developers can use

Measuring Value –

A Product Owner is tasked with maximizing value of the product and the most important metric from a Product Owners’ perspective will be those which has centred around the net value or the end value delivered to the final customer. Developers. on the other hand will see value of their work reflected into the quality of outcomes that they have achieved.

The table below shows some sample Metrics that can help the Product Owner and Developers measure “value”

Table 1 Scrum Metrics Around Value

Measuring Frequency –

Agile manifesto states the importance of delivering value early and in a continuous or frequent manner. 

To measure the frequency, a Product Owner will like to measure the frequency at which the Scrum Team is able to put the features or the work into hands of end user. However, Developers will want to measure the frequency at which they are able to turn out usable and useful increments. 

The table below shows some sample Metrics that can help the Product Owner and Developers measure “Frequency”

Table 2 Scrum Metrics Around Frequency

Measuring Day to Day Work

The Product Owner plays a critical role in order for the Scrum Team to be efficient and effective. Product Owner has to support the Developers and work as an integral part of the Scrum Team so that the increment created is of best possible value. Developers will want to ensure how they work together collaboratively and support each other while creating the increment. 

The table below shows some sample Metrics that can help the Product Owner and Developers measure “Day to Day effectiveness”

Table 3 Scrum Metrics Around Working Effeicently

Following are some of the articles on Agile Metrics

• Agile Metrics – Friend or foe
• What metrics should we focus on in Agile projects?
• Some sample Agile metrics
• Agile Metrics and Scrum Master
• Defining your own agile metrics framework
• Early warning signals of incorrect choice of metrics for your agile projects
• Velocity

The post Some Sample Agile Metrics appeared first on World Of Agile.

Can we use Traditional metrics as-is in Agile?

Figure 2 Traditional Metrics do not fit in Scrum

Traditional Metrics usually focus on measuring various aspects of planned versus actual. The idea is to track any variances against the detailed plan. They also measure quantum or size  of scope delivery. 

Intention of these metrics is to measure and showcase the efficiency of the delivery be it the schedule or cost adherence, Scope delivered or quality of the delivery.

Some of the usual metrics companies track are

1. Schedule Variance or Cost Variance
2. Size of work packets (KLOC / No of use cases / No of test cases etc)
3. Scope adherence – how we track Scope variance or rework and how we reduce the rework
4. Productivity  

The above metrics are set to track if we are delivering as per agreed plan. – But in Scrum and Agile the plans are changing often as we believe that while planning is indeed valuable – plans need to be updated often. Then these metrics to track against a plan do not seem relevant when plans are being updated very often.

Another key point missing in the above metrics is the focus on value – Agile Manifesto says that as agilists our highest priority is to deliver Valuable Software. The metrics listed above measure only “what work the team did” they do not measure “what Value was generated” – For a Scrum Team to ensure their effectiveness and efficiency we need metrics that can quantify the Value.

Do we need Metrics in Agile Projects?

We saw in earlier section that traditional metrics do not help when working in an Agile manner. The question then comes to mind is, do you really need metrics while working in Agile?

The answer is a definite yes – When done well, Metrics provide us with transparency by giving quantified information that does not depend upon individual perception. This quantified information helps us to inspect the work we are doing and the value we are delivering. The inspection then allows us to adapt our way of working to improve the value we deliver.

In other words, metrics help us to work in an empirical manner.

Figure 3 Why do we need Metrics in Agile?

What should we measure while working in Scrum?

In my experience there are 3 major dimensions where metrics provide us basis or the transparency to inspect and adapt

1. Value – Are we delivering Value? Scrum focuses on Value and our Product Owner is tasked in maximizing value of product. We need to have metrics that quantify and capture the value we have created. 
2. Frequency – Are we delivering value frequently enough so that we help our customers have competitive advantage? – Agile Manifesto tells us that we believe in continuous delivery of valuable products. 
3. Day to Day Metrics – These are the metrics which helps the Scrum Team to inspect and then adapt their way of working so that they become more effective and efficient.

The post Metrics in Agile Projects – What Should We Focus On? appeared first on World Of Agile.

How to create a Metric framework for your Program – How to choose Agile metrics, How to derive value from your Agile metrics?

 

Metrics are hot topic of discussion with Agile Enthusiasts. Both sides are equally passionate in their belief. Some people Believe that everything that can be measured should be measured. These people believe in the adage, “only what gets measured, gets improved”.  They insist that measuring the work progress, helps people to keep on track, to ensure that we are working up to our potential. They also argue that Metrics help baseline and these baseline data helps stake holders know what to expect

Other side of the coin are those people who object to this very “base lining” as they believe the comparison leads to people focusing on Metrics rather than value …They argue that metrics add overheads and often can be manipulated to paint whatever picture you want to depict. Often metric frameworks become bloated and defy the principle of simplicity. These are the people who believe that traditional metrics have no place in scrum way of working

The debt will go on. However, we all know that Metrics will always be part of work management for us. We need to find out ways to set up metrics which are not very cumbersome but still help us to take decisions based on quantified data. In this section I am planning to discuss all about Agile Metrics – Some topics I have in mind are

1. Do Agile Projects really Need Metrics? If yes, why we can’t use the same old metrics that we have been using for ages?
2. Some metrics that are useful in Agile or Scrum way of working
3. Metrics and the Scrum Master
4. How to set up a lean but efficient Metrics Framework
5.  What are some potential pitfalls you are likely to encounter?

Of Course, Metrics can never be defined in isolation – they need to be thought in context with your Agile contracts as well as your own scrum implementation. I hope this section helps you set up metrics that are useful for your own projects and products

The post Agile Metrics – Friend or Foe? appeared first on World Of Agile.

This article describes a routine Day in the life of a Scrum Master. A Scrum Master’s role is often misunderstood. People think that its a co-ordination role or worse still, Scrum Master is often considered a renamed “project manager”. The Scrum Guide says that Scrum Master is a true leader who serves. In this article I have shared some possible activities that I found useful as a scrum master in order to help the Scrum Team to implement Scrum – as defined in the guide and improve their effectiveness.

Day in the life of a Scrum Master – Supporting the Scrum Team(s)

Checking on the team space

Checking if everything is going fine could be a good start. Scrum master observes the team space to check if there are any infrastructure issues, anyone not able to work because of IDs locked out or zoom ID suspended etc. Scrum Master not necessarily checks with everyone however observation technique should be enough. If people are working remotely just a message on a messaging tool such as WhatsApp could be enough.

Sometimes human being related issues could affect. Resignations, unplanned leaves, sickness, demotivated team members could be some examples. It might be worthwhile for the Scrum Master to think about some suggestions that he/she might make to the developers or product owner during the day. 

Observation of Burn downs, Scrum Boards, impediment boards, happiness index

Observation of day to day boards, missing updates on scrum boards, deviations etc might be some good points for the Developers to talk to each other in the daily Scrum. If the developers don’t bring it up then politely coach them to discuss the deviations and what help they may need to bring things back on track.

Facilitation of Sprint Planning, Daily scrum, Sprint Review, Sprint Retrospective

Scrum Master does not run the daily scrum. However, Scrum Master must ensure that the daily scrum happens and developers know the intent. 

Many of the times daily scrums become a “show-off” forum for many people. Scrum Master must get the daily scrum back on track while ensuring people don’t get upset for stopping them. Saying things like 

“Hey Vinay, looks like you have done really substantial work on this aspect. Why don’t we have a coffee to discuss the same after the daily scrum. Anyone who wants to join is welcome”.

“Hey Dilip and Madhavi, it looks like you both are having a great conversation. Why don’t you do this after daily Scrum and I would also like to join the conversation if you both are ok? Anyone else wants to join the discussion, you are welcome as long as Dilip and Madhavi are ok”

Using facilitation techniques such as round-robin or tossing the ball after 30 seconds, those who have impediments first should speak etc could be good techniques.

Facilitation of Sprint Planning, Sprint Review

First, Scrum Master has to ensure that the Scrum Events happen and people know the essence of them. Other than the Daily Scrum (which is a daily event), Sprint Planning, Sprint Review and Sprint Retrospective are events which must happen in every Sprint.

Second, The participants of the meetings often do not come to conclusions and the meetings extend. Scrum Master should get the meetings focused and results achieved. For example, in a Sprint Planning, the Sprint Goal and PB Item selection should be done before the meeting ends. Sprint Review is about feedback process. Many a times the Sprint Review turns into a bashing forum for the stakeholders to bash the developers. Scrum Master should get the meeting focused back on the feedback rather than being a bashing forum or just a gate check forum.

Causing Impediment removal

There may be some impediments identified which the team may not be able to solve themselves. It might be worth contacting the right persons in the organization who may help with impediment removal.

Facilitating Product Backlog Refinements

Many times Product Owner and Developers come unprepared for Sprint Planning Events. This ends up being an understanding-of-requirements forum. The work should be split into smaller items much before and not during the sprint planning. Sprint Planning should be quick and should focus on any remaining clarifications. Understanding of what needs to be done over the next or next-to-next sprint should happen in a structured way in the form of product backlog refinement activity. While Scrum does not suggest any specific formats or timelines, it is worthwhile for Scrum Master to discuss it out with Product Owner and Developers on a frequency and format to understand the future. It is then worthwhile for Scrum Master to keep reminding the Product Owner and Developers on having the activity at a decided frequency to ensure that the Product Backlog is ready enough for the next couple of sprints.

Coaching, Mentoring, Teaching the Scrum Team in a Sprint Retrospective or elsewhere

Scrum Team members need help on various things on a day-to-day basis. They might get stuck on a problem (technical or non-technical). Scrum Master may wear a teacher hat if he/she knows the direct solution. Scrum Master may wear a mentor hat if direct solution is not known but if Scrum Master has faced similar problems in the past and help the team solve the problem using the experience. Sometimes if the solution is neither known to Scrum Master or to the Scrum Team, then one can wear the coaching hat and ask probing questions to lead the Scrum team to answers. This is usually done in a Sprint Retrospective but not limited to the forum.

Creating a safe environment and remove fear for failure

Many organizations look at failures negatively and there is a culture of punishing failures. On a day-to-day basis, removal of fear is an important activity. If there is a fear for failure then encouraging and motivating is an ongoing activity. Ensuring that team members don’t get exposed even if the failure happens is important. If the culture of punishing failures is not removed, people don’t try things and always take a safe route. This inhibits innovation and risk taking abilities.

Creating a culture of Self Management

Team members often wait for directions from seniors. Discussing and talking it out with people on self management is extremely important. On a day-to-day basis it has to be discussed with the Scrum Team on the importance of managing their own taks, allocating their own tasks, alignment of team members to goals etc. Scrum Master’s job is to get the team self managed and in fact not increase dependency on self.

Facilitating Release Planning

Workshop may have to be facilitated between stakeholders, Product Owner and Developers to plan releases. Scrum Master’s job is to make sure this happens and things don’t progress in an ad-hoc fashion.

Facilitating communication with managers

Managers many times indulge in ad hoc requests which may cause flow problems for the teams. Evaluating, discussing, negotiating with managers might be required many of the times. Developers might not be equipped to speak up due to various issues such as cultures, customer-vendor relationships, unrealistic service levels etc. 

Relationship Management

Causing Impediment removal for your team might be easier said than done. People help you because you help others. Scrum Master is a lot about relationship management. Other Scrum Masters might need help from you. Checking if you can extend help to others may be a good idea. One must ensure that you don’t go overboard on providing help. However , if you don’t do it then why would anyone extend help when you need it for your team.

Tools and techniques demonstrations

Looking at the day to day should instigate the scrum master to find out possible ways to improve productivity and reduce routine repetitive work. Finding out from other teams, other organization’s or researching may give some ideas for the Scrum Master to suggest to the Scrum Team. These tools and techniques demonstrations or presentations can be arranged for the Scrum Team.

Awareness about what is going on around

Catering to organization invites for what is happening in the organization is necessary. If you are not aware about what is going on then how would you know what to offer to your team?

Team Building activities

Scrum cadence introduces a lot of stress for people. Relieving stress via some team building activities may be a good idea to arrange for the team.

Floor meets

Creating the euphoria and excitement of a change is an important job of a Scrum Master. When organizational design changes happen, it is important to hold floor meetings, communicate the desire to change. While Scrum Master may not himself/herself do all this, facilitating the floor meeting with the help of HR and leadership is an important activity.

Day in the life of a Scrum Master – Supporting the Scrum Team(s) – Working in a Multi-Team Environment for a large product setup

Facilitating Scrum of Scrums

Multi-team products require dependency resolution on a regular basis. Scrum of Scrum forum is a good way for representatives of teams to talk to each other and resolve dependencies. Scrum Master should help create a cadence for these meetings and help the teams resolve technical and inter-team dependencies.

Facilitating Meta Scrums

Multiple Products in the organization may need Meta Scrum to discuss business dependencies, release planning process, process to organize release trains etc. Scrum Masters across multiple products should organize the structure by suggesting a cadence for the multi-product releases.

Facilitation of DoD creation

Multiple teams may go out of sync on the quality criteria and may end up with a product which does not meet customer expectations. Scrum Master must facilitate discussions between various teams to discuss the DoD among themselves and agree upon the quality criteria. This should happen regularly so that the quality improves consistently.

Day in the life of a Scrum Master – Working with rest Of the organization

Organizational impediments often impact the delivery of products. This may involve the different departments causing impediments or there may be organizational support required by the teams on the ground to get success

Preparing for attritions or career moves

Attrition, job-moves, role-changes are part and parcel of real life. As a Scrum Master one must facilitate knowledge sharing sessions, prevent formation of silo cultures, prevent the hero cultures in organizations. Honing and getting the new generation ready as team members move from one role to another has to be a well planned process. This requires facilitating with managers and Product Owner for budgets to onboard new trainees, training budgets, time for cross-skilling etc.

Creating and Nurturing communities

Impediment solving is easier said than done. Impediments are solved by a community of people and not by individuals. Nurturing communities and connecting people is the easiest way of solving problems. Scrum Masters of different teams should connect with each other and create communities for collaboration. This could be based on skills or cultures or regions. Many organizations call these guilds.

Coaching, Mentoring, Teaching the organizational players

Organizational players such as customers, management, HR, Administration may not be aware about Scrum, Agile or its benefits. They end up causing various impediments for teams. For example, some management’s take adhoc decision of using some framework such as Scrum. They may not know why they are doing it. HR might take decisions on individual rewards model not knowing what the implications of individual rewards in a collaborative environment are.

Facilitating Organizational Design Changes

As a change agent for the organization, the Scrum Master helps change the thought processes of the entire organization which may include Management, HR, Admin and other departments. Following could be some of the examples of organizational design changes brought about by the Scrum Master

Command and control leadership style to servant leadership style

Leadership is used to a particular leadership style. Many leaders resort to “Do it because I say so” kind of style. Servant Leadership style involves enabling the team to take decisions instead of forcing things on the team. This requires time and substantial convincing effort for the Scrum Master.

Establish Fear-free culture and creating a safe environment

One of the major issues with organizations is that the management is always judgmental of the people. Therefore, the team members rarely like to take risks. Being defensive may not always be the right behavior in the team. Scrum Master has to ensure that a safe environment is created for people to fail. This requires a lot of mentoring of Senior management and cultural change in the organizations. This requires a design change in the organizations in the way people think and the way people are appraised.

Feature teams vs Component teams

A Feature team takes end to end responsibilities of the product and creates viable products each sprint. To take end to end responsibility, the team restructuring and reskilling may be required. More importantly the culture within the organization may have to be relooked at. For example, the team needs to be cross functional to make a good feature team. That means, Scrum team needs to have all skills necessary within the teams to make products. This involves teaching and mentoring of the team members to find ways to build cross functional skills. The team members have to be made ready to not think in silos. Silo culture removal requires design changes such as convincing the team members, management and also making sure that the team members are ready for some cross training.

Collaborative mindset with vendors

Many a times the culture in the organizations is to look at the vendor as an outside entity. This creates divides between the customer and the vendor. Usually the PO accountability is taken up by someone from the customer side and the delivery is done by team members usually provided by vendors (usually in India in the IT world). If there is divide between the customer and the vendor, the collaboration gets affected and delivery may not happen properly. Scrum Master needs to make efforts so that the complaining mindset of many from customer has to go down and the vendor team members have to be made to feel a part of the product team. This needs Scrum Master’s effort in making thought process level changes in the organizations so that the collaboration happens. This may involve relationship building, confidence building and weeding out the bad behaviors – usually a long term design change.

The post Day in the life of a Scrum Master appeared first on World Of Agile.

As part of the Introduction to Scaled Agile Framework series, this article with cover the Scaling Conetx and Some Basic Concepts like where scaling fits and how it works.

Let’s first understand what Scaling is?

As a word, Scaling means there are multiple teams working on a Product (Value Stream). 

Scaling Agile refers to the process where the established Agile methods (Scrum/Kanban) are applied to other layers of organization.

Look at the Matrix below to understand the layers of the organization. 

In any Project organization the ratio of Product and Teams is:

• 1 Team working on 1 Product
• 1 Team working on Many Products
• Many Teams working on 1 Product
• Many Teams working on Many Products 

The Matrix above shows the context of Product v/s Teams.

• When we define a Product – here we define an Independent Value Stream which makes sense from a market perspective.
• When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
• Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts. Scaling is out of scope of Scrum.
• “Many Products – Many Team” context is defined by portfolio management, which is out of scope for most of existing scrum frameworks – SAFe is one of the most prevalent scaling framework that helps with
• “One Team – Many Product” quadrant is for Staff Pools who do heterogeneous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.

Context of Scaling and De-Scaling

When we think of larger products, we can think about descaling – that is, dividing the larger products first into smaller units of independent value streams (Products).

For the above product, the Scrum Context is that for each product (an independent value stream) there has to be a single product backlog, a single product owner and a single development team. Like the below diagram, each team works as an individual Scrum Team with their own “descaled” Product Backlog. There will have to be some considerations made to co-ordinate among the various dependent product backlogs. The diagram shows how the descaled products work.- Spotify is an example of framework which works on the principle of descaling

Context of Product Backlog and Product Owner

There is always a one to one relationship between a Product and Product Backlog and Product Owner. The context of the product backlog is shown below

The following structure where one is NOT OK. The accountability on the Product will go down if the following is implemented. It is better to descale the product instead of having a structure as shown below:

Context of a Product Owner and Development Team in Scaling

A Development team will always look up to Only one Product Owner.

A Development Team looking up to multiple PO means, the accountability is not central and conflicting decisions may come to the Development Team.

The post Scaling Context – Some Basics Concepts appeared first on World Of Agile.

Common Misconceptions

Most people consider Daily Scrum is presumed to be a Status Meeting where Scrum Master takes status from the teams. One of the most common reasons for this is because people have used Project Manager as an entity for years and assume that Scrum Master is a renaming of Project Manager role and Daily Scrum to be a new name for “Status Meeting”.

What is Daily Scrum Really?

• Daily Scrum is not a Status Meeting. Daily Scrum is a inspect-adapt forum for the Developers to make a plan for next 24-48 hours by checking if the Sprint Goal is being met or not
• Developers sync up daily so that the plan for next 24-48 hours is effectively done
• Updating the Sprint Backlog should be the main goal of the Daily Scrum. This optimizes the probability of meeting the Sprint Goal
• Daily Scrum is a effective forum for improving communication and collaborations between Developers

Recommendation about Scrum Master’s Role in Daily Scrum

• Scrum Master may facilitate the Daily Scrum to ensure it gets over in 15 minutes and people do not make it a detailed discussion forum. However, Scrum Master is not considered the compulsory participant of Daily Scrum.
• Scrum Master’s role is to make the team independent and help them becoming self-managed team. Therefore, Scrum Master should teach the Developers to run the Daily Scrum effectively by doing a quick sync up and updating the Sprint Backlog
• Once the team becomes self-managed and know how to get the Daily Scrum completed within 15 minutes, Scrum Master should change his/her stance to an observer stance. That means the team has to talk to each other without Scrum Master’s intervention
• Scrum Master should teach the Developers to keep the status transparent through various tools and techniques such as Burn Up Charts, Burn Down Charts, Scrum Boards. This avoids a lot of wasteful status discussions in the Daily Scrum
• Once the Scrum Master feels that the Developers are managing on their own, the Scrum Master should purposely skip a couple of Daily Scrum and find out if the Developers still keeps doing the Daily Scrum on their own. If the Developers also skip the Daily Scrum, just because the Scrum Master was not there, then Scrum Master should treat this as an opportunity to coach the team again
• If Scrum Master notices that Product Owner is conducting reviews of Product during the Daily Scrum, then, Scrum Master should coach the PO not to do it and create another forum where the review of the product could be done
• Similarly, if Scrum Master notices that the line managers are wasting the time of Developers by taking status, then Scrum Master must intervene and prevent the line managers from doing this
• Sometimes, one of the Developers wastes a lot of time of others during the Daily Scrum trying to dominate the forum by showing off on his/her skills. Scrum Master’s job to facilitate and ensure that everyone gets equal chance during Daily Scrum. There are many facilitation techniques which could be used. For example, tossing the ball every 60 seconds to the next person to speak, introducing friendly penalties (buying a drink for everyone, doing 10 push-ups) for exceeding the time allocated to speak etc.

Conclusion

Thus, Scrum Master is not a mandatory participant of Daily Scrum. “Not Mandatory” does not mean that Scrum Master is always Absent in Daily Scrum. Scrum Master’s role is to make the team independent so that they can manage the Daily Scrum to inspect and adapt and optimize the probability of meeting the Sprint Goal. Once the team becomes independent, it is better for the Scrum Master to take a step back and take observer position.

The post Myth – Scrum Master being the Mandatory participant of Daily Scrum appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do the Scrum Masters feel that they have to always protect the team?

• The earlier version of the Scrum Guide mentioned the following statement 

“The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team”. 

This was interpreted by most Scrum Masters that they always shield the team from the outside world.

• What ended up happening was that the Scrum Master became a liaison between the organization and the team. This way the Scrum Master became over-protective of the team and literally assumed the role of a “Dad” or a “Mom” for the team.

Some common observations when Scrum Master becomes overprotective

• Scrum Master deals with all impediments personally, even when the team members may be able to solve themselves
• Scrum Master filters feedback from stakeholders. Negative feedback is often not shared with the team. Only the goody-goody ones is shared with the team
• Scrum Master pampers the team by taking care of all administrative stuff (more like a PMO or a secretary)
• Scrum Master always becomes a bad-cop when it comes to harsh discussions with any stakeholder
• Scrum Master prevents the team from failing
• Scrum mom is not really challenging the team
• Scrum Master does not enforce boundaries and often remains too flexible with the boundaries
• “Right or wrong – its my team” behaviour starts getting seen

Negative consequences and what could be done

• Failure is not the opposite of success. Failure is in-fact a necessary stepping stone towards success. Like parents train their kids by letting go sometimes. Parents prepare the child for the real world by helping the child take up challenges. Scrum Master should allow the team to make mistakes and let go. There is no need to be over-protective. Let the team learn by failing. Scrum Master’s job is to keep showing the mirrors when failures happen.
• A Scrum Master’s good intentions can become an impediment for the Scrum team’s progress. This is particularly true in the case of an over-protective Scrum Master, when her shielding of the team prevents its members from learning by failing.
• Scrum Master’s job is to make the team independent and ready to face the world and not make them crippled by handling everything
• The greatest success of the Scrum Master is to see his/her team becoming Self Managed not needing a lot of bandwidth from the Scrum Master.

The post Antipattern – Scrum Master the (over) protector of the Team appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Scrum Master should solve all impediments

• In the 2017 version of Scrum Guide the accountability of the Scrum Master was mentioned as “Removing impediments to the Development Team’s progress;”. This sentence was often misunderstood and it was assumed that Scrum Master is the one who runs around and solves impediments.
• The term “Facilitator” is commonly misunderstood as a “coordinator”. Most teams come from a waterfall background and are used to having a Project Manager. In most organizations, the Project Manager is nothing more than a PMO who coordinates and does administrative activities. The essence of facilitation is to make it easy for the team to get to conclusions and decisions. Impediment solving is only one aspect of the Facilitation.
• Most organizations implement Scrum Master as a replacement for the PMO responsibilities and expect Scrum Master to run around and solve impediments.
• From the outside, this looks to be a great idea to have developers do the work and Scrum Master run around and get the administrative stuff done.

Negative Consequences of having a Scrum Master solve all impediments

• One of the fundamental elements of Scrum is “Self Management” where the team manages itself. The Scrum Master’s job is to teach the team to be self managed and cross functional so that they can get the work done.
• Team members other than the Scrum Master might be better qualified to solve an impediment
• People often then shrug off their accountability and expect scrum Master to be the PMO and even solve problems which they could solve internally
• Problems are often too complex to be solved by one person and therefore Scrum Master may not be the correct person to solve the problem
• Viewing an impediment from different angles helps to find effective solutions
• Many problems have to do with the way how people work together, solving such a problem cannot be done by one person

What could be done to avoid this anti-pattern

• The first line of defence for the team should be the team members themselves. The Scrum Master must teach the team to do this and not push everything into Scrum Master’s plate
• The Scrum Master should not get overloaded with solving impediments. The Scrum Master should be an observer, a coach and making sure that facilitation is done.
• For impediments which actually need Scrum Master’s help, only those Scrum Master should focus his/her attention on.
• Scrum Master should use his anticipation skills to anticipate issues so that the team can start looking for solutions a little bit in advance.
• In short, Scrum Master should become a coach and facilitator rather than just being a PMO.
• To clarify the actual accountability of Scrum Master with regards to impediment solving, the sentence has been reworded in the 2020 version of Scrum Guide to “Causing the removal of impediments to the Scrum Team’s progress” – which essentially means that it is not necessary that everyone just dumps all impediment solving on the shoulders of the Scrum Master.

The post Anti Pattern – Scrum Master the solver of all impediments appeared first on World Of Agile.