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

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