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.
The inputs to Sprint Execution are the Sprint Goal and the Sprint Backlog that were generated during Sprint Planning. The output from sprint execution is a Potentially Shippable Product Increment, which is a set of Product Backlog Items completed to a high degree of confidence—where each item meets the Scrum Team’s agreement upon Definition of Done. Sprint Execution involves planning, managing, performing, and communicating the work necessary to create these working, tested features.
It’s the team’s responsibility to manage the flow of work during Sprint Execution to meet the Sprint Goal. It must make decisions such as how much work the team should do in parallel, when work should begin on a specific item, how the task-level work should be organized, what work needs to be done, and who should do the work. When answering these questions, teams should discard old behaviors, such as trying to keep everyone 100% busy, believing that work must be done sequentially, and having each person focus on just her part of the solution.
An important part of managing flow is determining how many Product Backlog Items the team should work on in parallel to maximize the value delivered by the end of the Sprint. Working on too many items at once contributes to team member multitasking, which in turn increases the time required to complete individual items and likely reduces their quality. Just as working on too many items at the same time is wasteful, working on too few items at a time is also wasteful. It leads to underutilization of team member skills and capacity, resulting in less work being completed and less value being delivered. To find the proper balance, the recommendation is that teams work on a number of items together, an approach defined frequently by the term swarming, where team members with available capacity gather to work on an item to finish what has already been started before moving ahead to start work on new items.
Another dangerous approach would be to apply waterfall thinking at the Sprint level and treat Sprint Execution like a mini waterfall project. Using this approach, we would start working on all Product Backlog Items at the same time. First we would analyse all of the items to be worked on this Sprint, then design them all, then code them all, and then, finally, test them all.
Although this approach may seem logical, it is very risky. What if the team runs out of time and doesn’t finish all of the testing? Do we have a Potentially Shippable Product Increment? No. A reasonable Definition of Done would never allow untested features to be called done. By using a mini waterfall strategy, we could end up with 90% of each feature complete, but no feature 100% done. The Product Owner gets no economic value from partially done work.
Sprint Execution is not guided by a complete up-front plan that specifies what work will be done, when it will be done, and who will do it. Rather, Sprint Execution is performed opportunistically, leverageing the skills of the team, feedback from work already completed, and the evolving, unpredictable circumstances of the sprint. This doesn’t mean that Sprint Execution is chaotic, but rather that it is guided by the application of good flow management principles.