The daily scrum is designed for the team to coordinate and adapt its progress within the sprint. At a minimum, the product team should be in attendance. Typically, the invite list should also include the product manager and scrum master or delivery manager.
Although stakeholders and others outside of the team are generally welcome to attend, the intended audience is the team. Any attendees outside of the team should be observers only.

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

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.

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.

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

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

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.

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

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 Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

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.

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.