The definition of Done is about building the product “right,” and Acceptance Criteria is about developing the “right” product.

According to the 2020 Scrum Guide, “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint”. The definition of Done (DoD) is designed as a checklist, and it's used to check every user story for completeness or product backlog item. In other words, DoD is made to apply to all items in the product backlog, not just a single story.

The Acceptance Criteria of a User Story consist of a set of Test Scenarios that are to be met to confirm that the software is working as expected. It:

• applies to one Story/PBI,
• is different for each story,
• is used as a way of communication for all those involved to ensure that all story requirements have been met.

Therefore the product owner is responsible for specifying acceptance criteria and user stories.

Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Throughout a good agile project, you should expect to have user stories written by each team member.

Also, note that who writes a user story is far less important than who is involved in the discussions of it.

The Product Goal describes a long-term objective or future state of the product. It is a vital part of the Product Backlog, referred to in the Scrum Guide as a commitment. The Scrum Team uses the Product Goal to plan against and maintain focus.

Product Goals were added to the 2020 version of the Scrum Guide. The idea of incorporating this concept was to emphasize the importance of having a longer-term goal than a Sprint Goal. Plenty of research on self-managed, goal-oriented teams shares that goals give focus.

True leadership is a representation of the way you work with your team to achieve goals. A true leader makes an effort to help develop their team's skills so they can reach their full potential. They lead by example and establish strong, trusting relationships to ensure success within the team and for the organization as a whole.

A Product Owner must be an expert in the business domain and industry. To understand customer requirements better and translate them into product requirements, a Product Owner must be well-versed in business logic as well as the technical capabilities of the product. It is a diverse role that requires a mix of several skills and experience for high performance.

If the Product Owner has this authority, he can respond to the changing needs of the customer and the marketplace. If not, he is blocked from being effective and may need approval on all Product Backlog Item decisions which causes a waste of time, by the Product Owner, and waste in the effort, by the Scrum Team.

The product owner is a technical role. You can’t become a great PO if you don’t know the ins and outs of development, design, agile framework, software development, scrum approach, and IT infrastructure. Technical skill is defined as a specialized skill that is used to perform a specific task such as programming and software development. The agile product owner must be technically sound because backlog management and prioritization are technical tasks. It can’t be done effectively if the PO doesn’t understand the development and design processes and has no knowledge of how software development works.

Product Owner’s need is almost there on all the events except Daily Scrum because Daily Scrum is a time-boxed event for the Development Team to inspect and adapt daily. When a Product Owner is not available during the Sprint, it is one of the great impediments. It will certainly affect the ability of the Development Team to come up with a “done” product increment. If there is no Product Increment at the end of the Sprint, then the Sprint Goal cannot be reached.

In scrum, a product increment is whatever you previously built, plus anything new you just finished in the latest sprint, all integrated, tested, and ready to be delivered or deployed. Without a usable product increment, development teams are delaying the delivery of value and are missing opportunities to get real user feedback and adapt the product to ensure customer satisfaction. On the other hand, incremental releases allow for fast feedback, quicker innovation, continuous improvement, rapid adaptation to change, and more delighted customers.

A Sprint Goal is the result of a Sprint or what the Sprint should seek to achieve.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.

According to the Scrum Guide, "The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal".

The Team in Scrum is self-managing, and in order to do this successfully, it must know how it is doing. Every day, the Team members update their estimate of the effort remaining to complete their current work in the Sprint Backlog (Figure 6). It is also common for someone to add up the effort remaining for the Team as a whole, and plot it on the Sprint Burndown Chart (Figure 7 and Figure 8). This graph shows, each day, a new estimate of how much work remains until the Team is finished. Ideally, this is a downward-sloping graph that is on a trajectory to reach “zero effort remaining” by the last day of the Sprint. Hence it is called a burndown chart. And while sometimes it looks good, often it does not; this is the reality of product development. The important thing is that it shows the Team their progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in terms of progress), but in terms of how much work remains in the future – what separates the Team from their goal. If the burndown line is not tracking downward toward completion near the end of the Sprint, then the Team needs to adjust, such as to reduce the scope of the work or find a way to work more effectively while still maintaining a sustainable pace.

A stakeholder is "a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

Scrum Master Responsibilities:
1. Implement Project Management/Best Practices;
2. Keep all Parties on Track and Informed;
3. Introduce Agile Engineering Practices;
4. Coach Team Members;
5. Host Daily Stand-up Meetings;
6. Assist the Product Owner With the Product Backlog. It is the product owner’s responsibility to create and maintain the product backlog. The Scrum Master helps the product owner refine and maintain the backlog by using information gathered from standup meetings. They schedule review meetings and prioritize work on user stories.
7. Remove Roadblocks;
8. Teach Scrum Practices and Principles.

The output of a Sprint is a usable Product Increment. "Usable" means the stakeholders can see the product working as if it were released. The increment is the verified sum of all the Product Backlog Items completed during a sprint, plus all previous increments produced in the current and past sprints. Because of this, the increment needs to be integrated with the ones produced in past sprints. It must be in usable condition, regardless of whether the Product Owner decides to release it or not. The Product Owner is responsible for deciding when to release the Product Increment.

The Sprint Backlog represents the work that a Development Team needs to pull from the Product Backlog to achieve the Sprint Goal. The Sprint Goal is an objective set by the Scrum Team during Sprint Planning and captures the hypothesis that the team wants to test, a goal it wants to achieve, or an experiment to run. Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not. This would be unwise considering the core premise of Scrum: we can't create detailed plans for the future. Even if that future is a single Sprint, it is entirely possible that new insights or impediments emerge as the Development Team works through the Sprint Backlog.

A team might learn that a technology they picked does not perform as expected. Or a key feature needed to reach the Sprint Goal was missed during the Sprint Planning. As issues emerge, changes to the Sprint Backlog may be warranted in order to reach the Sprint Goal. The Development Team will then re-negotiate the Sprint Backlog with the Product Owner. In short; a Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.

The Daily Scrum presents Development Teams with an excellent opportunity to inspect and adapt upon their progress to the Sprint Goal and make adjustments to the Sprint Backlog when deemed necessary.

The Agile definition of done is a collection of criteria that must be completed for a project to be considered “done.” It is essentially a checklist used by Scrum teams to create a shared understanding of what is required to make a product releasable.

To fully understand the definition of done in the context of Scrum, we must first outline two of the key elements in Agile project management:

• Product backlog item: This is a specific improvement that is made to a product. Items can include bug fixes, user stories, and specifications.
• Product increment: This is what is produced at the end of a short development period or sprint. It combines all the product backlog items completed during this sprint.

In specific terms, the Scrum definition of done is a list of conditions that must be met to successfully mark a product increment as complete.

Scrum works not because it has three roles, five events, and three artifacts, but because it adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gathering customer feedback and embracing change.

It is important to prioritize the product backlog so that high-value stories are developed first during the daily sprints. The product owner, based on the product vision seen by the stakeholders and clients tries to prioritize the backlog based on:

• Business value
• Definition of ready

One of the main factors to consider while prioritizing a backlog item is to determine its business value and include that value in its definition. The business value is typically a number ranging from one to ten. The higher the business value, the greater the number. The business value is determined after considering several factors, such as:

• Client’s preference and priority in developing the feature;
• End-user requirements;
• Market demand for the feature;
• Levels of competition faced by other businesses developing products with similar features, etc.

The product owner assigns business values to the stories based on the extent of value or financial worth, the story can bring to the business and stakeholders once the product is developed and released in the market.