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.

Product Owner Core Competencies Framework

Product Owner is accountable for maximizing value. The article discusses core competencies a person must develop in order to become a great Product Owner.

The following diagram is created by our Certified Scrum Trainer, Amit Kulkarni based on his knowledge of delivering large products in various banks and financial institutions. This diagram in no way represents the exact view of how a Product Owner may be implemented in various organizations. This diagram is an attempt to visualize the knowledge areas one must focus on while one shapes his/her career in Product Management.

The above diagram is divided into three major areas

Must Have Competencies for the Product Owner

These are the necessary knowledge areas for a Product Owner. A product Owner must necessarily know about the product he or she is owning. Which means, the person should know about the Product Lifecycle, Managing Product Strategy Roadmap as well as the Product Backlog .

Should Have Competencies for the Product Owner

The knowledge areas which Product Owner should aspire once the “Must” areas are in place. These competencies deal about specific techniques which will help the Product Owner excel in the Product Management. A successful Product owner should definitely target to acquire many of the competencies and have a plan for where he and she can get help for areas where they do not have expertise them selves.

Could Have Competencies for the Product Owner

These are areas where the Product Owner may have some skills based on the work that the Product Owner has done before he/she has become a Product Owner. We can consider these as icing on the cake once the Product Owner has acquired the “Must” and “Should” categories of the competencies

Product Owner Core Competencies Framework © 2023 by Amit Kulkarni is licensed under Attribution-ShareAlike 4.0 International 

The post Product Owner Core Competencies Framework appeared first on World Of Agile.

Product Strategy Canvas

This canvas is built by our Certified Scrum Trainer, Amit Kulkarni. This canvas gives a glimpse of what fields could be included in a Product Strategy. This canvas is in no way the only way to document a product strategy. Each organization may have different canvas or templates to document the same. This Product Strategy Canvas is an attempt to give an overview of the fields one might use while documenting Product Strategy

Product Strategy Canvas © 2023 by Amit Kulkarni is licensed under Attribution-ShareAlike 4.0 International 

The post Product Strategy Canvas appeared first on World Of Agile.

Building Self Managed teams

Self Managed teams manage their own work, allocate work to themselves and track their own work. The Scrum Guide suggests that the Scrum Team be self managed. The common myths around self management and cross functionality are listed in another article “Myths around Self management and cross functionality“

This article is around “how” to help the Scrum team become self managed.

It is ok to make mistakes

Most organizations have no or very less tolerance for mistakes. Naturally, the teams become defensive and do not take up any risks. Less risks means lesser innovation and lesser possibility of building great products. Organization culture needs to encourage teams to try new things. Once the teams gets motivated and have a comfort feel that they will not be punished, the teams tend to take up work themselves. In short – the culture should be to encourage mistakes rather than discourage them.

Taking a step back

Great leaders take a step back and let the team take a step forward. Job of a leadership is to make the team independent and let them manage themselves. One of the major roadblocks is that the leadership is in a “decision making” mode. The “command and control” style of leadership style is sometimes assumed by the leadership. However, in a smart people industry, it is wrong to assume that the people on the ground are fools and cannot think. Leadership’s job is to enable the teams to start thinking and not penalize them for wrong result.

Another aspect of taking a step back is to make sure that the Scrum Master or the leadership does not become overprotective of the team. The Scrum Master has to let the team make mistakes and improve from the mistakes.

This is of course a big design change, however, needs to come into organizations if we have to let the team become self managed.

Move away from “Hero” cultures

Many organizations have a culture of rewarding the “heroes” thereby making them “super-heros”. In a short term, this may give results, but then, the hero-culture creates underlying issues.

• The Heroes shield information from the teams and the team actually remains where they are in terms of their knowledge and depth
• Once the heroes feel indispensable, there is a tendency to take the organization hostage and demand unreasonable things from the leadership
• Heroes create dependency and a culture where the hero becomes a bottleneck
• Hero burns out many times
• The team on the ground loses trust on the leadership since they start feeling that they are not needed

This is one of the major issues in making the team becoming self-managed. They always wait for the decision to be taken by the heroes and does not take accountability. The accountability of success and failure then shifts to the heroes.

No Hierarchies, No Sub-teams and No titles

• Hierarchical structure in side the teams creates a culture of depending on the “team-lead” for the decision. In this culture, the team on the ground does not feel empowered and is scared to take any decisions. In case of a wrong decision, the team members get reprimanded by the team-lead. Therefore the team refrains from taking any decision and just becomes a order follower of the team-lead. Even the leadership makes “team-lead” accountable for everything, so the team-lead is also reluctant to trust the team members on any decisions.
• Sub-team culture creates a “ping-pong” culture of throwing the ball into someone else’s court. The team members do not take accountability of their work and find it more convenient to throw the ball across the court on the other side.
• Creating Titles inside the team such as “senior”, “junior”, “trainee” creates divides. The “juniors” feel that it is the senior’s responsibility and the seniors feel that the juniors do not take accountability. In reality, even if the junior takes decisions, there is always a feeling in the seniors that the junior is taking away their job or junior is trying to poke their nose inside senior’s work. This creates divides within the team and a major hurdle in making self-managed teams.

Scrum Master / Product Owner should not be the manager or boss of the team

Many companies organize the teams in such a way that the team on the ground reports to Scrum Master or the Product Owner. When this happens, the fear of getting reprimanded or fired from the job prevents the team on the ground from taking their own accountability. The team on the ground then becomes an order follower and wait for Scrum Master or Product Owner for assigning the day-to-day tasks. This again becomes one of the hurdles in making the teams self-managed.

Rewarding teams instead of individuals

Many organizations have reward cultures where individuals are singled out and rewarded. This creates a sense of dis-satisfaction within the team members. Most of the time, it is not about a single individual – it is the team-work which makes great products. Instead of creating awards like “star of the month” or “star of the quarter” or “star of the project”, the awards should be more like “star team of the month” or “star team of the quarter” or “most collaborative team of the month”. This creates a team-culture rather than an individual culture. Creating a self-managed team is about building trust among the team members and they should all enjoy the success. It should not be one individual enjoying the fruits, it should be the entire team.

Building cross functional teams

Most people feel that cross functionality is all about having all skills within one person. This is very difficult to achieve. When we talk about cross functionality, it is about the “team” having all skills within the team to make things happen. This is much more practical. To make a self-managed team, it is important that the team recognizes what skills are missing and works towards bridging the skill gap.

Building end-to-end accountability with feature teams

The traditional team structures are horizontal structures where a particular component such as coding or testing is managed by the team. This results in team not able to take end-to-end accountability and tends to put the blame on the other component when the things do not work. Feature team builds end-to-end accountability and helps the team to think of product or feature as a whole instead of thinking of it as a part.

Conclusion

Making a self-managed team is a journey. It is a major organizational design change. This requires the Scrum Master / Agile coach to help the team understand how to get the team to become Self Managed. This article has presented some tangible ways in which self management can be started off.

The post Building Self Managed teams appeared first on World Of Agile.

Myths about Self Management and Cross Functionality

Myth : self managed team means do whatever the team feels

Self managed teams do have rules. Just that the rules are set up by the team members and not my managers. These rules are typically called the ground rules or working agreements. Scrum Master’s job is to make sure that the team members decide the ground rules, else, there are possibilities of conflicts.

Myth: cross functionality means each person has all skills

Each person having all skills is a common myth. Expecting this means each person is a Superman or a Superwoman which is very unrealistic. Cross functionality is for a team and not for each individual. “as a team” do we have all skills necessary to do the work. This is generally achieved by “T shaped” skills. “T shape” means one core skill and multiple supplementary skills. The team does what is necessary as a team to achieve the results.

Myth : You cannot have self managed teams in waterfall teams

A team can manage itself even in a waterfall. This is a team characteristic and not specific to Scrum or Waterfall. In the waterfall model, it was a common misconception that Project Manager always has to be command and control leader. There was no such need. However, since the accountability of everything was put on project manager, the project manager naturally turned out to be a command-and-control leader. Therefore, the teams rarely self-managed in waterfall.

Myth : Self Managed teams are less sincere in their work

A team which manages itself is generally a highly motivated team. This team works without pressure from a manager and take their own accountability. The sense of accountability and ownership is much higher in a self managed team.

Myth : Self managed teams create shoddy quality since there is no one to monitor and control them

This is again a common misunderstanding that there is no monitoring and controlling of work. A self managed team decide internally how the monitoring and controlling of quality, timelines, cost is done. External manager does not do this. This is managed internally by the team members.

Myth : No one manages conflicts in a self managed team

Self managed team tries to resolve conflicts by communicating with each other. If inspite of all efforts the conflicts do not get resolved, there is always a Scrum Master for helping resolve the conflicts.

Conclusion

There are lots of myths about self management and cross functionality. This article was an attempt at listing down some of the myths around self management and cross functionality. There is another article on how to build self managed team – click on the link to read the article.

The post Myths about Self Management and Cross Functionality appeared first on World Of Agile.

Product Owner is the accountability in Scrum which Maximizes the value to the stakeholders using the bandwidth available to him/her via the Developers.
While the requirements can never be finalized in empirical work, one of the fundamental aspects of reducing wastage in Agile is to get the requirements ready for the developers “just in time” – not to early and not too late.
Product Owner’s role is to engage with the stakeholders and understand their needs and expectations. This involves

• Requirement elicitation techniques
• Need Analysis techniques
• Requirements classification techniques
• Collaborative Gaming techniques
• Requirements classification techniques
• Requirement Documentation techniques

Who does requirement elicitation in Scrum?

While the Product Owner remains accountable for requirements elicitation, rarely would a Product Owner have enough time to elicit it by himself/herself. Generally, Business Analyst does this (Business Analyst is called as Developer in Scrum) for the Product Owner. Elicitation techniques help people to understand the thoughts and feelings of participants, and to probe for more information.

Why is requirements elicitation different in Scrum?

In Scrum, requirement elicitation is an ongoing job. The Product Backlog emerges throughout the project. Therefore, doing too much of upfront elicitation is a lot of wastage. However, doing the requirements elicitation should ensure that the process is quick, and bureaucracy involved with signoffs and baselines should be avoided. At the same time, the process has to be fast. You cannot have huge documentations done in the form of a Functional Specification or Business Requirements Specification.

Requirements Elicitation Techniques

• Brainstorming technique
• Focus Groups
• Interviews
• Prototypes, simulations, demonstrations
• Wireframes
• Nominal group techniques
• Voting techniques
• User story splitting

Requirements Classification Techniques

• Idea / Mind mapping
• Affinity Diagrams
• Multi-criteria decision analysis
• Wideband Delphi

Collaborative Gaming Techniques

• Remember the future
• Prune the product tree
• Sailboat technique

User Role Modeling Techniques

• User Proxies
• User Persona
• Extreme Persona

Need Analysis Techniques

• Five Why techniques
• Cause and effect diagram
• Cause and effect matrix
• SWOT analysis
• Value Stream Mapping

Process Flow Techniques

• Process flow diagram
• User Cases
• Spaghetti diagram
• Swimlane flowchart
• SIPOC diagram

Requirements Documentation Techniques

• User Story
• Context Diagram
• Use Case Diagrams

Business Rules Formats

• Business Rules Catalogue
• Decision Trees

Data Formats

• Entity Relationship Diagrams
• Data Flow Diagrams
• Data Dictionary
• State Table and State Diagrams

Interface Formats

• Report Table
• System Interface Table
• User Interface Flow diagram

The post Generally Accepted Product Management Practices appeared first on World Of Agile.

Conventional, long standing advice regarding transitioning to Scrum or any Agile process has been to start with a pilot project, learn from it and then spread agile throughout the organization. This approach is the frequently used start-small pattern in which an organization selects typically one to three teams, gets them successful and then expands Scrum from there.

Start Small or Go All-In

Reasons to prefer starting Small

• Starting Small is less expensive
• Early Success is almost guaranteed
• Starting Small avoids the big risk of going all in
• Starting small can be done without re-organizing

Reasons to prefer going All-in

• Going all in can reduce resistance
• It avoids problems created by having Scrum and traditional teams work together
• An all-in transition will be over more quickly

Patterns for Spreading Scrum

Getting started with scrum is one thing; spreading it across the organization is another. Unless you have chosen an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum into other teams. There are three general patterns you can use for spreading Scrum beyond the initial teams.

1. Split and Seed

The Split and seed pattern is typically put into use after the first couple of teams have adopted scrum and run at least a handful of Sprints. The Split and Seed pattern works in the diagram depicted below.

Reasons to prefer split and seed are

• You can add teams more quickly than with most other approaches
• Each team has someone with scrum experience to help guide them

2. Grow and Split

In this pattern, it involves adding team members until the team is large enough that it can be comfortably split in two as shown in the figure.

Reasons to prefer Grow and Split are

• You don’t have to destroy any existing teams
• Team members feel more continuity from sprint to sprint

Internal Coaching

Coaches are given some specific responsibilities such as attend Sprint Planning , Review and Sprint Retrospective Meetings, attend one Daily Scrum each week and be available for two hours each week to provide other assistance to the mentored team as needed.

Reasons to prefer internal coaching are

• Well-running teams do not need to be split
• Coaches can be hand-selected for new teams
• Coaches can be moved from team to team

Choosing an Approach

There are two driving factors

• How quickly do we need to spread Scrum to additional teams
• Do we have good internal coaches who can assist the new teams?

In general, consider using split and seed when you are in a hurry. The Split and Seed can be the fastest approach to spread Scrum through the organization.

The grow and split pattern is perhaps the most natural approach as it mirrors what would probably happen if no one intervened to help the spread of Scrum

Consider using grow and split when there is not enough urgency to push you to split and seed approach.

Internal coaching can be used as a spreading strategy on its own or it can be used to augment either of the other approaches. The internal coaching approach works the best when

• The group is large enough that good practices won’t fully spread on their own
• When Splitting teams is not practical for your projects
• When you have enough internal coaches or can bring in outside help

The Enterprise Transition Community

The small group that initiates, encourages and supports an organization effort to introduce and improve at Scrum is known as the Enterprise Transition Community or ETC. The Enterprise Transition Community exists to create a culture and environment where the changes can be released by those who are passionate about the success of the organization and where success leads to more passion from more people. The ETC does this not by imposing changes on the organization but by guiding groups who are implementing changes by removing obstacles to doing Scrum well, and by creating energy and excitement for the change.

The members of the ETC, who usually number no more than a dozen, come from the highest level involved in the transition to Scrum. If a company is adopting Scrum organization-wide, the ETC should include senior people from engineering or development plus vice presidents of groups such as product management, marketing, sales, operations, human resources and so on.

The ETC is responsible for :

• Articulate the context
• Stimulate conversation
• Provide resources
• Set appropriate aspirations
• Engage everyone
• Anticipate and address people issues
• Anticipate and remove impediments
• Encourage a simultaneous focus on practices and principles

Reference for Good Reading on this Topic : Mike Cohn’s Book, Succeeding with Agile

The post Transitioning to Scrum appeared first on World Of Agile.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

·      For the Product Backlog it is the Product Goal.

·      For the Sprint Backlog it is the Sprint Goal.

·      For the Increment it is the Definition of Done.

The post Commitments in Scrum appeared first on World Of Agile.

Let’s understand the connection between various philosophies, methods and Scrum framework.

First a definition of what the terms Philosophy, Framework, Methodology and Standards mean

• Philosophy: Broad values and principles which people follow. Philosophy is more of a mindset than telling you actually how to do things.
• Framework: Framework is a bare minimum essential guideline under which you operate and solve specific types of problems. E.g. Scrum and Kanban are frameworks which give broad guidelines.
• Methodology: Methodology gives guidelines about tools, techniques and sometimes includes a framework to operate too. It is not necessary that an approach of describing everything is always great. Most times, methodologies are over-defined and a lot becomes irrelevant for use. Some of the methodologies are PRINCE2 by Axelos, Extreme Programming (XP)
• Standards: Standards collect best-practices, tools, techniques, processes which are generally used in the industry. It’s basically a collection of various things put together. For e.g. PMBOK by PMI is a standard of project management.

Lean

Lean is an effective way of eliminating waste and implementing Customer Value focus. Lean is the over-arching philosophy consisting of the 5 broad principles as described as: 

Within the umbrella of lean, there are various other philosophies are prevalent in the industry – DevOps and Agile being the most widely used philosophy

Agile

Agile is a philosophy and consists of thought processes which are summed up in the Agile Manifesto. Agile Manifesto consists of 4 values and 12 principles. The 4 Values are

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

Some of the key thought processes on which Agile principles are based on are

• Focus on Value
• Elimination of wastage and improvement of productivity
• Respecting Change
• Iterative and Incremental Delivery
• Collaborating teams
• Working with variable scope
• Focus on working product
• Time boxed delivery
• Focus on continuous improvements

Most Agile values and Principles are directly complying to the broader Lean philosophy.

Scrum

Scrum is a framework to handle complexity. Scrum complies to all of the agile principles and values in some way or the other. The framework consists of the 3 Artifacts, 5 Events and the Three Roles which are the minimum in handling the complexity in work effectively.

DevOps

DevOps is a philosophy. DevOps isn’t a framework or methodology in and of itself. It doesn’t stand alone. DevOps adopts and leverages multiple frameworks and methodologies such as agile, lean and ITSM. DevOps is benefited tremendously from the work the Agile community has done, showing how small teams, operating with high-trust, small batch sizes with smaller, more frequent software releases, can dramatically increase the productivity of development organizations.

ITSM

IT service management (ITSM) is the activities that are performed by an organization to design, plan, deliver, operate and control information technology (IT) services offered to customers – commonly called Support/Maintenance/Production Support services. Various Six Sigma tools, XP techniques, software development techniques, DevOps Tools are used.

Six Sigma

Six Sigma is a set of statistical quality improvement techniques which can be used to achieve Agility or become Lean. Without quality, the product may not deliver value to the customer. Hence the Six Sigma techniques are used frequently while executing work in various frameworks such as Scrum, Kanban, XP.

The post Connection Between Lean, Agile, DevOps, Six-Sigma, ITSM, Scrum appeared first on World Of Agile.

A particular way in which something is done, is organized, or happens:

• The pattern of family life has been changing over recent years.
• A pattern is beginning to emerge from our analysis of the accident data.
• In this type of mental illness, the usual pattern is bouts of depression alternating with elation.
• Many behaviour(al) patterns have been identified in the chimp colony.

– Cambridge Dictionary

Scrum is a framework which is intentionally kept incomplete. Scrum Does not describe tools, techniques and practices. They evolve as practitioners use them. Some of the practices become widely used and people find them useful. Whenever the practices become widely used we may call them “PATTERN” of how practitioners use them.

We can also say that Scrum is a set of patterns or practitioner experiences. Some of these patterns have been made mandatory. For example, Scrum consists of an event Daily Scrum. We can say that “Daily Scrum” is a pattern used by practitioners and most find it useful. Scrum therefore mandates that there be an event known as “Daily Scrum”. So, we can say, Scrum consists of a few mandatory patterns such as “Scrum Master”, “Product Owner”, “Developers”, “Sprint Planning”, “Daily Scrum”, “Sprint Review”, “Sprint Retrospective”, “Product Backlog”, “Sprint Backlog”, “Increment”, “Definition of Done” and so on.

However, other than the mandatory Scrum Patterns, we may use non-mandatory patterns in the Scrum Framework. For example, can we use a “Definition of Ready” as a pattern to define readiness of a product backlog item? can we use “Information Radiator” as a pattern to transparently display the Sprint Backlog?

The Scrum Community documents a lot of patterns on Scrum Plop website. These set of blog articles are based on Amit and Snehamayee’s experience of working in a Distributed World and still delivering large agile projects and making agile implementations possible in a distributed world.

Also many patterns emerged when people started working from home after the pandemic began in 2020. Agile still worked. Scrum still worked. So we can say, practitioners found a way out. These set of blog posts will attempt to capture certain experiences which have emerged after the start of the pandemic.

The post What is a Pattern? appeared first on World Of Agile.