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.

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.

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.

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.

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.

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.

As new information is learned, the team must negotiate with the Product Owner regardless of what it is. If the Developers feel strongly about something they think something needs adjusting, they are responsible for communicating the changes to the Product Owner before acting.

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.

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.

Kanban and Scrum are project management methodologies that complete project tasks in small increments and emphasize continuous improvement. But the processes they use to achieve those ends are different. While Kanban is centered around visualizing tasks and continuous flow, Scrum is more about implementing timelines for each delivery cycle and assigning set roles.

Methodology comparison between Kanban and Scrum:

1. Roles: Kanban has no defined roles. Scrum has a Scrum master, Product Owner, and Development Team.
2. Delivery cycle: Kanban is continuous. In Scrum, the Sprint cycle lasts one to four weeks.
3. Change policy: For Kanban, changes can be incorporated at any time. In Scrum, changes are generally not made during the sprint.
4. Artifacts: Kanban uses a Kanban board. Scum has Product backlog, sprint backlog, and product increments.
5. Tools: Kanban uses Jira Software, Kanbanize, SwiftKanban, Trello, Asana. Scrum uses Jira Software, Axosoft, VivifyScrum, and Targetprocess.
6. Key concepts or pillars: Kanban is about Effectiveness, efficiency, and predictability. Scrum is about Transparency, Adaptation, and Inspection.

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.

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.

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