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

This series will review the three primary Agile Planning Horizons utilized by organizations for Agile Development, along with general guidelines, pros & cons, and “entry criteria” guidelines that should be considered essential in order to adopt and deliver. For Part 1, we will provide a summary overview of the three most common Agile Planning Horizons. For Parts 2 – 4, we will provide a more in-depth description of each Agile Planning Horizon:​

• Flow / Kanban / “Scrum-ban”​
• Sprinting (classic Scrum)​
• Program Increment (Scaled Agile)

Overview

The term Agile Planning Horizon refers to the Agile Planning process used to identify, prioritize, “queue up”, and deliver work in an Agile organization.​

In general, the “right” Agile Planning Horizon for a team (or a group of teams) will be chosen based on:​

• The nature or type of work being delivered​
  • Rote or repetitive work (Flow)​
  • Complex work involving risks, unknowns, interdependencies or uncertain requirements (Sprint)​
  • Complex work at large scale (Program Increment)​
• The planning timeline – whether and to what extent the work can/should/must be planned in advance​
• The Agile Maturity or Agile Capability of the organization

Summary​

• ​

Flow

• The Agile Framework known as Flow is also commonly referred to as Kanban or “ScrumBan” (where a daily scrum is utilized by the team). This is a “just in time” delivery framework where the highest priority work is identified and delivered in a continuous flow. The main objective of this Framework is THROUGHPUT.​

Flow is best for work that is routine or repetitive; work that is well understood, common, or frequent. It is ideal for Helpdesk or Operational Support work – work that cannot be planned or is ad hoc and doesn’t require detailed pre-planning. Flow is also a good choice for teams or organizations that are not mature in Agile Practices due to a few key factors:​

• There is no requirement for a time-boxed planning and delivery cadence. Work can be introduced and reprioritized at any time​
• There is no requirement for defined, specialized roles (Product Owner, Scrum Master, etc.)​
• There is no requirement for team members to have a cross-functional skill set; if a team has a specialized skill set, they can adopt this lightweight Agile Framework.​

Flow is poorly suited for delivering the work where:​

• The work is unfamiliar to the organization (“building new”)​
• The work is complex, with upstream or downstream dependencies that need to be coordinated and negotiated or agreed to​
• The work requires team members to possess multi-disciplined skill sets (e.g., full stack development)​
• The work requires collaboration with stakeholders, vendors, or other external teams

Sprinting

• ​The Sprinting Agile Planning Horizon is used by Scrum teams to rapidly and iteratively deliver complex and high-value work in defined timeboxes called Sprints; in a Sprint, work is planned and delivered on a fixed cadence.​

Scrum teams consist of 3-10 team members and perform three defined roles:​

• Product Owner (PO) – The PO is the customer representative who owns the backlog and work requirements, and prioritizes the work to be delivered by the team. The PO is responsible for accepting or rejecting the delivered work on behalf of the customer.​
• ScrumMaster (SM) – The SM is a servant leader who works to build and maintain a high-performing team, facilitate the various scrum ceremonies, remove blocks and impediments, and keep the team focused and on track.​
• Team Member – The team members deliver on the product vision by iteratively building the high-value work required by the customers. The collective team should possess all of the skills and capabilities required to deliver the work. The team members own grooming, refinement, and estimation of the backlog. The team also owns the “Sprint Commitment” – the team’s commitment of what will be delivered in a given sprint.​

Sprinting is best for work that is complex, where the requirements or technology are uncertain – where negotiation and collaboration are required. The priority and requirements of the work to be delivered are understood at general level, so that the work can be planned and delivered within a few sprints. The Planning Horizon is on the scale of weeks to a couple of months. Sprinting is also ideal for situations where the team is able to frequently collaborate with stakeholders or customers to agree on detailed requirements and where negotiation can happen during the delivery process.​

Sprinting is not recommended for organizations that cannot commit DEDICATED resources to fulfill the Scrum roles continuously; further, the organization should commit to building Scrum teams that are “sticky” where Team Members are dedicated to their teams and are not swapping in and out of teams. Further, sprinting is not a good choice for situations where delivery requirements are unstable and constantly changing. Sprinting is not the best fit for organizations whose stakeholders are not consistently available to engage, collaborate, or provide critical feedback.​

Program Increment (PI)

​The PI is the timebox artifact of a Scaled Agile organization, where multiple teams are working from a common “Portfolio-Level” backlog towards delivery of large-scale, strategic solutions. The PI Planning Horizon consists of numerous sprints during which all teams are synchronized on the same timebox cadence so that all teams coordinate and cooperate in the PI planning event as well as the ongoing execution of the committed PI plan. A PI will typically span 2-3 months on the calendar (basically this will be a Quarterly Planning Horizon). In general, any Scaled Agile Framework will have extra layers of communication and control to enable Agile practices for large or very large groups.​

In a Program Increment Planning Horizon, numerous Scrum Teams form a Release Train; for very large-scale solutions, multiple Release Trains form Solution Trains.​

• Release Train – A team of teams in synchronous cadence and executing in concert against Portfolio or Program level product goals​
• Solution Train – An organized group of release trains in synchronous cadence and executing in concert against Enterprise or Portfolio level product goals
• ​​
• Source: https://d2o2utebsixu4k.cloudfront.net/media/images/1544077632343-A-Value-Stream-can-have-many-ARTs-within-it.jpg​

In addition to the Scrum Team roles which exist at the Scrum Team level (Product Owner, ScrumMaster, Scrum Team Members), in a Scaled Agile Framework there are also some additional roles:​

• Product Manager – This role owns, defines, and prioritizes the Program Backlog. The Program Backlog is what populates the Product Backlog, which is owned by the PO at the Team level. At very large scale, Portfolio Managers own and define the Portfolio Backlog which feeds into the Program Backlog.​
• Release Train Engineer – This role acts as “Chief ScrumMaster” for the Release Train; the RTE helps to build and support the teams in the Release Train, facilitates PI ceremonies, and removes blocks/impediments at the Release Train level. At very large scale, Solution Train Engineers perform similar duties at the Portfolio or Enterprise level.​
• System Architect – Provides architectural guidance and technical enablement to teams in the Release Train. At very large scale, Enterprise or Solution Architects perform similar duties at the Portfolio or Enterprise level.​

A Program Increment Planning Horizon works well for large organizations which are mature with Agile development practices, who seek to deliver Enterprise-wide, “Market-making” capabilities at a (relatively) rapid pace.​