Agile Planning Horizons (and How to Choose Them) – An Enterprise Guide – Part 3

Following from Parts 1 and 2 of this series, which provided a high-level overview of three common Agile Planning Horizons, this article provides a closer look at the Sprinting Planning Horizon.

Overview – Sprinting Planning Horizon

Sprinting is an Agile Planning Horizon used by Scrum teams to rapidly and iteratively deliver products of the highest possible value within timeboxes called Sprints. Sprinting is a fixed cadence of iterative cycles (typically two weeks but not shorter than 1 week and not more than 4 weeks).  The short delivery cycles and collaborative nature of Sprinting makes this framework ideal for projects with rapidly changing, highly emergent requirements.

Roles in the Sprinting Framework

There are three primary roles in the Sprinting / Scrum framework:

• Product Owner (PO) – The primary job of the product owner is to be the customer representative (the voice of the customer), turning the vision into a workable product backlog for the team to execute and managing the return on investment/business value of the product or service under development. The product owner brings clarity to the vision of the product to be delivered and works with customers and stakeholders to build the list of requirements that makes up the product backlog. The PO owns the product backlog, sets priority of the work, defines requirements and acceptance criteria, and ultimately accepts or rejects the work delivered.
• ScrumMaster (SM) – The role of the ScumMaster is multi-faceted. The SM works to build and maintain a high-performing team, manages the various scrum ceremonies, removes blocks and impediments, keeps the team focused and on track, and keeps a view of the big picture while looking for places where the team can make improvements. The SM also has a role of protecting the team’s collective health and protects the team’s “psychological security” to operate properly.
• Scrum Team Members – The team members deliver on the product vision and build the functionality needed to implement features from the prioritized product backlog. The Scrum Team should range between 3 to 10 members, and the collective team will possess all of the skills and capabilities required to deliver on the product vision. The Scrum Team should be composed of “T-shaped” individuals – which is to say that, while they may specialize in a particular technical area, they have a broad range of technical capabilities. The Scrum Team owns grooming & refinement of the backlog to get stories to a “ready to work” state. The Scrum Team also owns the “Sprint Commitment” – which is the team’s commitment for what work will be delivered in a given Sprint. They own end-to-end development, testing, documentation, and delivery of valuable product functionality.

Ceremonies

In the Sprinting framework, teams conduct numerous ceremonies to plan work, deliver work, and inspect & adapt for continuous improvement.

• Sprint Planning – During the planning meeting, the team reviews the stories, estimates against team capacity and priority, and commits to the delivery of this body of work within the Sprint timebox. 
• Daily Standup – During the Sprint, the team participates in a Daily Standup to review work done the day prior, coordinate the work to be delivered that day, and identify any impediments/blocks to be resolved on that day. 
• Backlog Grooming/Refinement – Also during the Sprint, the team holds a number of backlog grooming & refinement meetings to prioritize and estimate the work that will be needed for subsequent Sprints. 
• Retrospective – At the end of the Sprint, the team reviews the work delivered vs what they committed to in Sprint planning.  They take stock of what went well and what did not.  They also identify initiatives for continued improvement, and when possible, they create stories for the next Sprint to account for taking that improvement action.
• Sprint Demo – At the end of the Sprint, the team demonstrates the functionality completed to stakeholders and takes feedback for additional iterative changes/improvements for future Sprints.  These action items are then represented in the Product Backlog and prioritized for delivery in subsequent Sprints.

Artifacts

The work artifact for a Sprint is the Story.  Generally, one or more stories make up Features which represent a unit of functionality that delivers considerable business value and fulfills a customer need.  In the Sprint planning horizon, a team commits to and delivers stories which are needed by the Customer.  Delivery of features can span more than one Sprint, whereas delivery of stories should be contained within the Sprint that the story was committed to.

Typically, the stories will have more robust requirements, acceptance criteria, and task lists than a Kanban issue.  The Sprint stories will also include an estimated weight (in story points), and they will generally have some way to document the actual time spent for review and measurement in the Retrospective following the Sprint.

Stories on the sprint board will also generally identify which Feature/Epic they contribute to – they will identify the initiative or sprint goal that each story is aligned to.

The Sprint Board

Generally, the sprint board is similar to a Kanban board – the main difference is that it represents a specific timebox with predetermined start and end dates.  There can be more “status” columns or labels for the stories on the board, including identification of blocked work, work that has upstream/downstream dependencies, or work that is a “stretch goal” for a sprint.

Pros and Cons

Pros

Here are the conditions which lend themselves to a Sprinting-based planning horizon. The Sprinting framework is ideal for:

• Complicated or complex projects where the requirements or technology (or both) are uncertain; stakeholders may not be certain about what technology will be best for achieving the desired value, or what the final product will look like (but they know what they need).
• The priority and requirements of the work to be delivered are understood and accepted at a general and broad-enough level that the work can be planned and delivered within 2 – 8 weeks. This is to say that the business is “certain enough” about the product needs & requirements that the scope can be “locked” and committed for delivery within the sprint “timebox”; further, the delivered capability will be useful and valuable upon delivery.
• Situations where the Team needs to collaborate with customers/stakeholders to discover and identify the detailed needs/requirements, and where flexibility and negotiation can happen in the delivery process.

Source: [“The Scrum Field Guide” by Mitch Lacey]

Cons

Here are the conditions which DO NOT lend themselves to a Sprinting-based planning horizon:

• The organization cannot commit DEDICATED resources to the effort for all three Scrum roles (PO, SM, Team).
• Delivery requirements are unstable and change continuously.
• Stakeholders and/or customers are not consistently available to engage, collaborate, or provide critical feedback. Stakeholders and/or customers are unable or unwilling to actively participate in the Sprint process.
• Roles lacking authority – individuals are designated to conduct a Scrum role without the authority to make concrete decisions for the team or organization they represent.
• The inability to contain or control “Helicopter Managers” – Managers who undermine the Sprint framework by asking individual team members for work or support which is not sanctioned within the Team’s Sprint Commitment – and the lack of authority on the part of the SM, PO or Team Member to stop this behavior.