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.

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.

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.

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

People think that just by moving to Scrum all their issues will get resolved and magically all timelines will be met, no budgets will ever get overrun, all people will be happy, all customers will be happy, all changes come free and so on….

What Really is Scrum?

Scrum is a framework for solving Complex Adaptive Problems. Complexity means “Unknown-ness”. The Unknowns can be on requirements or on solutions. Where things are unknown, you cannot make detailed plans and just track the plan to closure. In such situations where things are unknown, what you see in front of you can be the only decision factor. Taking decisions based on what you see and constantly Inspect and Adapt based on what you see is called “Empiricism” or “Empirical process Control”. Scrum is a framework which sits on the “Empirical Process Control Theory”. For known problems (requirements known and solutions known), you will not need the inspect-adapt approach. The approach used for known problems is called “Defined Process Control”. Waterfall framework is based on “Defined Process Control”

Recommendations

One must understand that Scrum does not necessarily reduce cost and timelines. In Empirical process control, there will always be a feedback structure since the decisions are taken based on what you see. That means, we think about short-term in detail and long-term at a high level. When we see the results of short-term, we get feedback and then we inspect and adapt based on what we see. Therefore, there may be repetitions due to the feedback structure. Repetitions may mean that some re-work may happen. One must not think that just by doing Scrum, the cost and time will be lesser. If we use Scrum for problem statements which could have been solved using waterfall (or Defined process control), then unnecessary overheads and unnecessary inspect-adapt cycles may increase the cost and timelines. My recommendation is to choose the right framework for the right purposes. Taking a “one-size-fits-all” is not a great idea.

The teams are not necessarily happy doing Scrum. In the Scrum way of doing things, the timeframes are short. Delivery cycles shrink to a few week cycles. There is a constant pressure on teams. Many times, you will notice comments in the team like “Waterfall was better”. Scrum is actually Pervasive. That means people don’t like this drastic change in their lives. This change touches people’s lives. My recommendation is to ensure that every organization first implements a culture which sustains this pressure. The earlier model, where there was “push culture” should change first. Management should not create unnecessary pressure on the teams. Agile principle number 8 should be implemented first “Agile processes promote sustainable development. Sponsors, Developers and Users should be able to maintain a constant pace indefinitely”

The business teams are not necessarily happy doing Scrum. The Business teams were used to pushing accountability conveniently on the technical team’s side under the umbrella of a few terms like “Managed Services” or “Managed Outcomes”. The IT companies also marketed these terms like “Managed Services” to create differentiators for themselves. The Business teams suddenly start feeling the heat when they are held accountable for ensuring that the delivery happens properly and making sure that they have to work with the technical teams on a day-to-day basis. In Scrum, we define the accountability “Product Owner” where participation from a Business perspective is extremely important. My recommendation that the Business Teams must be made to understand that Accountability cannot be outsourced and one cannot toss the accountability on the technical side. The business should be brought in sync with the Agile principle “Business People and Developers must work together daily throughout the project”. Scrum emphasizes that the right people take the right accountability and accountability cannot be outsourced.

The Business teams have conveniently understood that “Changes are free in Agile and Scrum”.  One has to understand that no changes are ever free. There is always a cost associated with a change. It is just differently looked at in Scrum. In Scrum, we tend to give importance to more valuable features. That means, the less valuable features go down the product backlog and may never get implemented. So, pushing the teams to do all requirements may not be a great idea, else the cost will obviously go up. My recommendation is to follow the Agile principle number 10 which says “Simplicity – The art of maximizing the work NOT done is essential”. The business has to know that nothing in this world is free and we need to learn to compromise less-value features for the more valuable ones

Conclusion

Scrum is not a magic-wand solution to solving all problems. In fact, if you do things incorrectly then the problems will multiply. It is better for organizations to understand Scrum and Agile correctly and apply only where required. “One-size-fits-all” is not a great approach.

The post Myth that Scrum is a Magic Wand to Solve all Project Issues appeared first on World Of Agile.