Following from Parts 2 and 3 of this series which provided an overview of the Flow and Sprinting planning horizons, this article provides a closer look at the Program Increment, a Scaled Agile Planning Horizon.

Overview

Program Increment is a timebox artifact of SCALED AGILE operations. PI represents a committed Enterprise or Portfolio vision and execution plan. A PI is timebox for delivery of a Value Stream which is executed by “teams of teams” which are organized as Release Trains or Solution Trains.

• Release Train – A long-lived team of Agile teams which delivers solutions in a value stream. The Release Train operates in synchronous cadence and practices regular, organized cross-communication around blocks and dependencies
• Solution Train – An organized group of release trains that is focused on building large and complex solutions under a shared, over-arching business/technology mission.

• Source: https://d2o2utebsixu4k.cloudfront.net/media/images/1544077632343-A-Value-Stream-can-have-many-ARTs-within-it.jpg

The Program Increment (PI) itself is a series of sprints (usually 4-6 sprints) in which multiple teams operate on a shared sprint cadence to deliver on one or more committed objectives of the PI.

The PI framework is an Enterprise-level synchronization of Agile Teams to deliver on large-scale enterprise objectives. Naturally, this requires large-scale synchronization of cadence and planning ceremonies across all teams. This includes daily or weekly syncs as needed (i.e. Scrum of Scrums and/or PO sync). This isn’t a status report. Instead, it is about communicating and coordinating about blockers/impediments, dependencies and “sequence of event” needs in order to ensure results are accomplished within the PI timebox for ALL teams in the train.

By synchronizing the PI planning and the following sprints across all Teams and Trains tasked with delivery, cross-domain planning is enabled. As a result, the Scaled Agile organization benefits from:

• Structured Cadence
  • Improved predictability
  • Improved stakeholder confidence in wait times for committed capability
  • Support for regular planning and cross-functional coordination
  • Limitation of batch sizes of work to discrete intervals
  • Scheduled integration points
• Synchronized Cross-Domain Planning
  • Improved control of injection of new work
  • Improved and routine dependency management
  • Supports full-system integration and assessment
  • Multiple feedback perspectives
  • Facilitates the ability for all stakeholders to engage with each other at the same time
  • Requirements and design planning occurs in a comprehensive way
  • Important stakeholder decisions are accelerated
  • Trains and Teams create and take responsibility for the PI plans created
  • Sequences and dependencies are understood and accounted for among Trains and Teams

The PI Planning Horizon requires a focus on dependencies and sequence of execution across teams for the purpose of achieving aligned Enterprise goals. A more detailed overview of the Program Increment can be found here: [https://www.scaledagileframework.com/program-increment/]

Ceremonies

There are a number of ceremonies which typically occur within the PI:

PI Planning – PI Planning is a Scaled Agile ceremony (usually lasting 1-3 days), in which multiple teams gather to establish, plan, and commit to the objectives to be delivered collectively by the teams. Each team will create and commit to its own objectives, but these will be in alignment with an over-arching vision and roadmap. The ceremony should have a standard agenda which starts with a presentation of the business context and vision, followed by team breakouts where each team’s plans and commitments are established and presented. A more detailed overview of this ceremony can be found here: [https://www.scaledagileframework.com/pi-planning/]]

Scrum of Scrums and PO Sync – Teams should have a built-in schedule to sync every 1 or 2 weeks (or more frequently if needed) to coordinate around various team or train dependencies and review progress and impediments to make plan adjustments as needed. This sync can occur as either a Scrum of Scrums or a PO Sync, or it can be combined into a single ceremony, as appropriate.

System Demo – The system demo is held collectively at the end of each sprint among all Teams in a Train. The objective is to demonstrate the current state of the solution overall, and gather feedback from sponsors/stakeholders/customers at the “Train Level”. This ceremony should be an integrated demonstration that provides an objective measure of functionality, progress, and ultimately value of the work delivered so far within the PI. This feedback provides an opportunity for the Train to validate its progress against PI objectives and/or to make course corrections. At the end of the last sprint in the PI, there is a “Final System Demo” which is delivered in the same way, and should be a fully integrated demonstration of the functional product achieved in the PI against the committed objectives. A more detailed review of this ceremony can be found here: [https://www.scaledagileframework.com/system-demo/]

Inspect and Adapt Workshop – The Inspect and Adapt Workshop is held at the end of the PI. It should include all of the teams and stakeholders who participated in PI Planning and/or were involved in supporting the execution of the PI. This event allows the teams and stakeholders to inspect the end result of the PI and engage in collective exercises for the purpose of continuous learning and improvement. The workshop consists of three parts:

1. Final System Demo
2. Quantitative and Qualitative Assessment
3. Retrospective and Problem-Solving Workshop

A more detailed review of this ceremony can be found here: [https://www.scaledagileframework.com/inspect-and-adapt/]

Artifacts

Capability (or “Solution Capability”) – A Capability is a higher-level behavior or functionality that is identified, planned, refined, and committed for delivery by the Solution Train; typically the Solution Capability is delivered by multiple Release Trains. The Capability is composed of one or more Features and is sized to fit within the PI. Capabilities are usually created by Product Managers in collaboration with Product Owners and other key stakeholders. Capabilities are structured like features, but they are at a higher level of abstraction, describing system-level behavior and function in support of the definition and development of large solutions. Solution Capabilities comprise Strategic Solutions: the products, services and systems delivered to the customer.

Master Feature – In some Scaled Agile organizations or contexts, Master Features exist to help enterprises organize and group related Features. Master Features have the same properties as Features and Capabilities (overview, statement of benefit, and acceptance criteria) but exist at a level of abstraction higher than that of a Feature but lower than that of a Capability.

Feature – A Feature is a service or functionality that fulfills a stakeholder need.

The Feature is the primary artifact, which is identified, estimated, and groomed to “ready state”, and ultimately planned and committed to by the Release Train within the sprints of a Program Increment.

The feature should include a description of the service or function as well as a statement of benefit and acceptance criteria. The Feature is composed of one or more User Stories. Features are typically created by the Product Owner, with Solution (or System) Architects commonly creating enabler features that will be required for delivery of the functional Features and Capabilities. Features are committed to by Release Trains at the PI level, and the constituent Stories are committed to by Teams at the Sprint level.

Additional information about Features and Capabilities can be found here: https://www.scaledagileframework.com/features-and-capabilities/

Roles

Product Manager – The Product Manager is responsible for the Program backlog and roadmap, which is the definitive repository required to meet the upcoming release objectives, support strategic initiatives at the Program level, and provide the overall product vision and roadmap. The Product Manager works with Product Owners to ensure that Features being developed deliver the value and meet the needs of customers and stakeholders based on the overall PI objectives.

Release Train Engineer (RTE) – The RTE is a Scrum Master of Scrum Masters, acting at the Program level to coordinate resources, actions, planning, execution against commitments, removal of impediments, and ultimately results of multiple Scrum Teams at the Program level.

Solution Train Engineer (STE) – The STE is a Scrum Master of RTEs, acting at the Portfolio level.

Product Manager/Director – Senior product leader who understands the big picture and manages multiple Product Owners.

• Owns and manages the delivery Roadmap on a timescale of 2 or more Quarters ahead.
• Owns leadership sponsorship when newfound knowledge requires a pivot of scope or initiative, and manages the governance required.
• Engages senior leadership to establish and hold to commitments made.
• Communicates upstream, while maintaining situational awareness of tactical work in flight.

Solution Architect – Operates at senior management or executive level – ensures that the Product Manager(s) remain aligned with strategic objectives and empowers them to fulfill commitments.

• Owns the Strategic Roadmap, commitments, and delivery at the Portfolio level.
• Maintains situational awareness of Solution Trains in flight.
• Resolves organizational blocks – works with the Enterprise to surface and resolve impediments before they block workflow.

Enterprise Architect – The Enterprise Architect is responsible for the optimization of manual and automated processes into an integrated environment. They act as lead architects by directing, integrating, and facilitating the work of Solution Architects while working on the target and transition architecture.

Executive Sponsor – Leads or sponsors Portfolio-level planning, sets priorities and objectives at the Enterprise and/or Portfolio level. Confirms scope, priority, and value delivery objectives and supports teams to deliver on them.

Pros and Cons

Pros

• Well-led and capable organizations can deliver “market-wide” and “market-making” disruptive capability at rapid pace, and in a manner that can be sustained and iteratively enhanced by the enterprise.
• Establish an “Enterprise-wide” culture of sustainable achievement, technical excellence, and continuous improvement.
• Leverage institutional deep knowledge and human capital to rapidly introduce innovative and competitive capabilities, and keep the best assets of the enterprise engaged and delivering great value over a long period of time.
• Provides a framework for removing non-performers at the enterprise level.
• Provides a framework for promoting and enabling high performers at the enterprise level.

Cons

• Requires a VERY high level of leadership, organizational communication, and collaboration capability – generally across multiple “traditional” silos.
• PI Planning is a resource-intensive exercise that requires Executive-level commitment, communication/coordination, and follow-through. It requires not only a great effort for all teams, but it also requires executives to “get their hands dirty”, which tends to be one of the biggest challenges.
• All of the requirements of the Sprinting framework, PLUS:
  • Executive-level understanding and leadership of Agile practices at a “hands-on” level. Talking about this topic is usually insufficient – Executive Champions will need to get involved with their vision and support, and live up to the responsibilities they ask of their teams.
  • Leadership-level accountability, honesty, and open communications among Enterprise peers is REQUIRED. (This is a big ask for traditional leadership who are focused on controlling their own silos.)
  • Enterprise-level ability to commit and dedicate the needed resources without behaving as a “Helicopter Manager”.

Entry Criteria

The entry criteria for an organization to adopt and implement Program Increment Planning Horizon is high. The organization should have multiple teams with experience and some level of maturity operating Scrum-based Agile development. Organizations should have strong competence with the Agile roles in addition to a clear Executive Vision for what is to be delivered, including:

• Fully engaged Executive Product Leadership who is accountable for the performance and roadmap of the entire Product organization
• Teams with the ability to operate Scrum (2-6 teams with similar performance and capabilities should be required)
• ScrumMasters should be capable, fully committed, and engaged in their roles
• Product Owners should be capable, fully committed, and engaged in their roles
• Dev Teams must be capable, committed, and engaged in their roles

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.

Following from Part 1 of this series, which provided a high-level overview of three common Agile Planning Horizons, this article provides a closer look at the “Flow” Planning Horizon.

Overview: Flow Planning Horizon

Flow is a “just in time” delivery framework where the work is prioritized and visualized on a Kanban board.

The main objective of Flow is THROUGHPUT – the goal is to complete the highest priority work in a continuous flow. This is accomplished by MINIMIZING the work in progress (WIP) so that the team/individual only works on one thing at a time until that work is DONE, then they pull the next highest priority item from the “to-do” stack. Sometimes, work gets blocked waiting for external input or approval – in this case, teams can use a “blocked” column and pull the next highest priority item, but blocked items must be the top priority of any work in flight and be worked as soon as it becomes un-gated.

Because work is continuous flow, it does not need to be estimated. Daily standups are not required but often prove to be beneficial – this type of Flow is often referred to as “Scrum-ban”. Retrospectives are not required, but in practice they should be held at some regular interval (e.g., monthly) to review the team’s performance, throughput, and quality, and to address common impediments that should be resolved within the organization.

Work is visualized on a Kanban board. The Kanban board uses separate columns to identify work to do next, work in progress, and work completed.

• The “To Do” column is a prioritized list of work to be done, where team members pick from the top of the list when taking on new work.
• The “In Progress” column is a list of the work “in-flight” and being delivered at any given moment.
  • The “Done” column represents the list of work completed. In Flow, this can also be two columns – an “In Review” column is often used to show work that is completed but requires review and acceptance in order to be considered “Done”. In this case, there will be a “done” or “accepted” state where the work is catalogued for historical record and measurements of the flow rate / velocity.

The Kanban board – Example:

Source: [https://leanicontechnology.com/what-agile-methodology-is-best-for-your-development-teams-in-2020/]{.ul}

Key elements to visualize:

• Criteria required for any work item to advance to the next workflow state. For example: Items in “to-do” need to meet some definition of “ready to work” (clear requirements, data inputs identified, etc.) Items in “in progress” need to meet some standard definition of done such as dev complete for all acceptance criteria/requirements, test complete, unit test or code coverage requirements complete & documented, etc.
• WIP limits – according to the team standard set and agreed upon, work in flight must remain within this limit to ensure smooth and “ASAP” throughput

Pros and Cons

Pros – Here are the conditions which lend themselves to a Flow-based planning horizon

• The work is routine or repetitive (i.e., the work is well understood, common, frequent)
• Helpdesk or operational support work – teams dedicated to working defects arising from an established production process or product/application
• Work that is not plannable, or doesn’t require a detailed/defined pre-planning process (ad hoc work)
• Work that is simple enough to not require regular and holistic inspect & adapt cycles
• Teams that are not mature in Agile
  • Specialized roles are not required (product owner, scrum master, etc.). However, many organizations find it beneficial to have a role that:
    • Owns prioritization, completeness requirements, and removal of impediments
    • Monitors throughput and delivery results, facilitates continuous improvement
  • Agile ceremonies are not necessarily required (but often beneficial) such as daily standups, backlog grooming, work planning and commitment, demonstrations of functionality
  • Work doesn’t go through a grooming/refinement and estimation process
  • There is no requirement for strict adherence to team size guidelines per Agile Scrum team best practices (typically 3 to 10 individuals)
  • There is no requirement for truly cross-functional capabilities of the team; often Flow teams can be composed of people who are specialized in one or a few types of work; they don’t require a truly cross-functional skill set in the same way that an Agile Scrum team does.
  • There is no time-boxed cadence (though this can be a double-edged sword and lead to bad habits and inefficient processes unless it is managed and worked with discipline)

Cons – Here are the conditions which DO NOT lend themselves to a Flow-based planning horizon

• Work that is unfamiliar to the organization (“build new” versus “known process”)
• Work that is complex; work that has upstream or downstream dependencies that must be coordinated and negotiated (i.e., work that needs to be planned for execution both within and outside of the team)
  • This is especially true for work that is composed of features/epics and strategic initiatives where there are many functional parts that make up a larger whole of value to be delivered
• Work that requires multi-discipline skillsets for delivery of work (e.g., UI work, middleware, database, architectural design, security & compliance scope, etc.)
• Work that requires a high degree of stakeholder, vendor, or other external collaboration and partnership