Scrum practices and values put emphasis on collaboration and communication. The performance appraisal creates an agenda divide as the employee uses it to try to highlight his or her performance in order to get raises and promotions, while the manager uses the appraisal to divvy up scarce departmental resources. Both agendas can be a motivation for conscious or subconscious distortion of the data, or to behaviors that ultimately benefit the person doing them, but not the company or customer. The appraisal fosters low trust competition in the team rather than self-organizing to meet customer needs.

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.

A new Sprint starts immediately after the conclusion of the previous sprint, and each Sprint typically begins with Sprint Planning and ends with Sprint Review & Sprint Retrospective.

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 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.

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.

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.

“A Scrum Master leads through influence, not authority.”

Attendance is not limited to the Scrum Team. When it’s needed, for example, for refinement, the Scrum Team can invite SMEs to provide additional information. This could also include users, the client, or any other stakeholder. This makes the event more engaging, as well as shows you value the opinion of others.

Agile scrum artifacts are information that a scrum team and stakeholders use to detail the product being developed, actions to produce it, and the actions performed during the project. The main agile scrum artifacts are product backlog, sprint backlog, and increments.

The term artifact is often associated with archaeological ruins and ancient relics. Yet in software development, the term artifact refers to key information needed during the development of a product.

Agile scrum artifacts are information that a scrum team and stakeholders use to detail the product being developed, actions to produce it, and the actions performed during the project. These artifacts provide metadata points that give insight into the performance of a sprint. They are essential tools for every scrum team since they enable core scrum attributes of transparency, inspection, and adaption.

According to the 2017 Scrum Guide:

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

In 2020 it has been changed to:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value for each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

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.

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.

Trust is the bedrock of self-organizing agile teams. Trust allows agile teams to communicate quickly and respond rapidly to changes as they emerge. Without sufficient trust, team members can waste effort and energy hoarding information, forming cliques, dodging blame, and covering their tracks. A climate of trust provides the foundation for effective team processes, adaptability, and high performance.