Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

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.

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.

Sprint is a short period in which a team works to produce an end deliverable. Within each sprint, there are Scrum inspect and adapt events. Also known as ceremonies, these meetings are held by the Scrum team to clarify the purpose, progress, and results of a particular sprint. There are four Scrum inspect and adapt events in total: sprint planning, daily Scrum, sprint review, and sprint retrospective.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum's success and usage. The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interactions between them.

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.

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.

In the Scrum agile framework, a Sprint Planning meeting is an event that establishes the product development goal and plans for the upcoming sprint, based on the team’s review of its product backlog.

Although sprint planning sessions can at times benefit from input from various members of an organization, the key participants in any sprint planning session will be:

• The Scrum Master (who typically runs and coordinates the meeting).
• The Product Owner (who will explain the product backlog items, answer backlog questions, and help define the sprint goal).
• The Development Team (who will make commitments to the work, estimate timeframes, and explain any capacity or skill-set issues that could prevent work from getting done).

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.

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.

Product Backlog refinement is an ongoing process in which the Product Owner and the Development Team collaborate on reviewing and revising detail, estimates, and orders for items in the Product Backlog.

The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. The Product Owner isn’t part of the Development Team and can invest as much time as necessary and enlist the help of other members of the Scrum Team.

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.

The Scrum team can estimate either during product backlog refinement or during sprint planning events.
The objective of the Estimation would be to consider the User Stories for the Sprint by Priority and by the ability of the team to deliver during the Time Box of the Sprint.
Agile teams usually estimate effort using a metric called story points. Story points are the abstract value that takes into account the relative complexity and size of a task. Teams tend not to estimate based on person hours, but instead use Story points – a concept inherited from Extreme Programming (XP).

By definition, a Sprint cannot be longer than one calendar month. Therefore any so-called Sprint of a longer duration will be invalid, and it would mean that Scrum principles are not being followed.
Note that the Agile Manifesto allows up to two months between each delivery of customer value, albeit with a preference towards shorter timescales. Iterations of greater than a month may therefore be arguably agile, although they would not be Scrum-compliant.
Also, bear in mind that Scrum Sprints must result in *potentially* releasable increments and that the time between actual releases may therefore exceed one month. However, if the release of an increment equates to the delivery of customer value, and if the release is deferred for longer than two months, then the Scrum implementation (although strictly valid) would not conform with the principles of the Agile Manifesto.
Therefore be sure to time-box Sprints to no more than one month in length, and aim to release an increment into production at least every two.

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. However, the frequency of their inspection should not affect their work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.