The Sprint Goal is prepared during the Sprint Planning by the whole Scrum Team.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Product Owner is responsible for ordering the items in the Product Backlog to best achieve goals and missions, thereby optimizing the value of the work the Developers perform. How this is done, and what value means, may vary widely across organizations.

Scrum is:

• Lightweight

• Simple to understand

• Difficult to master

The Product Owner is responsible for ordering the items in the Product Backlog to best achieve goals and missions, thereby optimizing the value of the work the Developers perform. How this is done, and what value means, may vary widely across organizations.

As new work is required, the Developers adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Developers can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint, and it belongs solely to the Developers.

Of course, it's not mandatory (the concept of Stand Up Meeting isn't even mentioned in the Scrum Guide) but it's best practice as it helps the Developers to keep the Daily Scrum within 15 minutes.

What is a Daily Scrum?

Daily Scrum is a daily 15-minute time-boxed meeting in the Scrum framework where Developers briefly share their progress and plans for the day. The goal of Daily Scrum is to ensure that everyone is aligned on the goals of the Sprint, identify and address any obstacles, and improve communication and collaboration among the Developers.

When maximizing the flow of value, the Product Owner needs to consider the business value, user's unmet needs, effort to complete the item, availability of Developers and skills, dependencies within the product and outside of the product, etc. The Development tools and techniques and the availability of the Scrum Master has no direct impact on the flow of value.

In Scrum, a Sprint is considered complete when the time-boxed period of development work is over.

Non-functional requirements describe qualities of the Product being developed. For example, the Product should be secure and extensible. The only way to meet such requirements is to have them as a part of the DoD and check every Increment against these criteria.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is a standard for any work done on it.