In Scrum, work is confined to a regular, repeatable work cycle, known as a Sprint or Iteration. Scrum Sprints are fixed intervals, ranging from one week to one month with preference to shorter periods. Working within the boundaries of such an accelerated time-frame, the team would only be able to build the most essential functionality.
A Release is typically composed of multiple Sprints, each of which delivers customer or user value. Every Sprint begins with Sprint Planning, a time when the Scrum Team gathers to agree on a Sprint Goal and determine what it can deliver during the forthcoming Sprint.
Sprint Execution accounts for the majority of time during a Sprint. It begins after Sprint Planning and ends when the Sprint Review starts. On a two-week-long Sprint, Sprint Execution might account for about eight out of the ten days.
Sprint Execution is the work the Scrum Team performs to meet the Sprint Goal. During the Sprint, the Development Team self-organizes to produce a Product Increment in accord with the Sprint Backlog, as determined during Sprint Planning. Self-organizing means that the team responsibly produces the Product Increment in accord with all the organization’s standards, according to the Definition of Done, and that the Development Team determines just how to go about that.
The Scrum Master participates as the coach, facilitator, and impediment remover, doing whatever is possible to help the team be successful. The Scrum Master doesn’t assign work to the team or tell the team how to do the work. A self-organizing team figures these things out for itself.
The Product Owner must be available during sprint execution to answer clarifying questions, to review intermediate work and provide feedback to the team, to discuss adjustments to the Sprint Goal if conditions warrant, and to verify that the acceptance criteria of Product Backlog Items have been met.