Velocity is a key Scrum metric that measures the amount of work a team can deliver during a sprint.

During Sprint Planning, the team’s velocity is used to determine the number of product backlog items to tackle. Based on this, the amount of work and the delivery date can be estimated. At the end of the Sprint, the actual velocity will be used in the calculation for the next one.

The Sprint begins with Sprint Planning and ends with the Sprint Retrospective. Each event depends upon the successful completion of the previous event to ensure that teams can inspect and adapt. If the Daily Scrum for a Sprint happens before the Sprint Planning event for that Sprint, the team can’t inspect their plan and adapt it because they don’t have a plan yet. If the Sprint Planning event for the next Sprint happens before the Sprint Retrospective for the previous Sprint is completed, the team can’t adequately plan for the upcoming Sprint. They don’t yet know what improvements they will be making to their interactions, processes, or tools for the upcoming Sprint.

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.

The product backlog is a list that contains and prioritizes the details of every little task you require to include in your product. If you want to make any changes to your product, then product backlog is the only source of requirements. A product backlog never completes; you have to work on the product backlog list continually. The product backlog continuously evolves to recognize what your product requires to be perfect, useful, and worth the competition.

The product owner is the only owner of the product backlog. When it comes to maintaining and organizing the product backlog, the product owner holds complete accountability. While ordering the backlog, the product owner may get influenced by customer priority, difficulty in relative implementation, the urgency of receiving feedback, etc. An efficient product owner will look for feedback from the development team, customers, and designers to optimize product delivery.

The Scrum Master, the Scrum Team, and other Stakeholders contribute to having a broad and complete To-Do list. You can allow other cross-functional team members to contribute items to the product backlog.

The best way for a team to estimate its product backlog items is in story points and its sprint backlog tasks in hours.

This works well because story points are a more abstract measure that individuals with different strengths can agree on. Just as you and I can agree on the length of the measure “one foot,” even though our individual feet are most likely different lengths, so can agile team members of different skills agree that this user story will take twice as long to do as that user story.

Story points don’t work, though, at the sprint level. During sprint planning, remember the goal is for a team to determine how much work to bring into the sprint. That’s hard with abstract units like story points. It’s far easier with hours.

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.

Only the Development Team can change its Sprint Backlog during a Sprint. If the Product Owner wants to change the work planned, he has to do this per the Development Team.

The Sprint Backlog is, ultimately, a plan for the Sprint. The development team executing work inside of a Sprint creates a Sprint Backlog. The creation occurs during the Sprint Planning. The central question is, how does this work get done? The Product Owner presents a list of prioritized items from the Product Backlog. The team will analyze the list, do capacity management, figure out what they can do, and make a plan to execute. The Sprint Backlog is a plan to achieve the overall goals of the Sprint.

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 Scrum Guide does not prohibit this. Wearing "two hats" can be challenging to fully attend to all expectations of the Scrum Master role and be a focused Developer. Although it is helpful to understand more about Development work, it can also be a pitfall.

According to the Scrum Guide, “The Development Team is responsible for all estimates”.

The Scrum Guide states that the Scrum framework is designed to deliver products of the highest possible value. It also states that “the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team” (guide). For the Product Owner to be able to decide what Product Backlog Items will maximize the value, he or she has to take into account what it will cost to deliver these items.

We already concluded that Scrum is a framework that is suited for complex work. We also concluded that in this domain the best estimates are made by those that perform the actual work. The Scrum Guide agrees and is very clear on this: “The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.”

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.

In the Scrum framework, it is important for Scrum Teams to deliver a valuable Increment as frequently as they can — at least once per Sprint. Each Increment brings the team and its stakeholders one step closer to a valuable Product Goal. Without this, it is difficult to learn about what else is needed and to reduce the risk of complex work. The Product Owner is responsible for maximizing the value of the work done by the developers.

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.

The 2020 Scrum Guide defines an increment as ”a concrete stepping stone toward the product goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. To provide value, the Increment must be usable…The entire scrum team is accountable for creating a valuable, useful Increment for every Sprint”.

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.