Most software Product Owners would agree that planning for the work that the Agile development teams will undertake is a mix of both art and science.
While the “art” is driven off of a mix of experience, point in time information, fire of the day, and gut feeling, the “science” is often left behind. Additionally, the appropriateness of art vs. science differs depending on the target backlog: Tactical or Strategic.
Agile Backlog Planning
Agile organizations work off of clear work hierarchies that help to align all the way from the organizational structures down to specific work assignments. Of course, this alignment is crucial to ensure that the actual work is directly supporting an overall strategy for a Product or Program.
Any Product Owner knows that backlogs are living breathing entities that are constantly evolving. And as they evolve and grow, they can also quickly get out of control and work is prioritized by the loudest voice at the table. A refined backlog is the healthy foundation of any successful agile planning exercise.
Agile Backlog Planning must be accomplished simultaneously at both a Strategic and Tactical level. It is this duality that that can easily diverge to where the day to day management of agile teams work may not be well aligned to what the organization strategically wants to accomplish.
The Art of the Tactical Backlog
The Tactical Backlog lives down at the Story, Bug, Refactoring level. There are often metadata and other indicators used by Agile teams to assist in informing this planning and prioritization. These can include but are not limited to:- Interdependencies – Foundational work must precede other dependent efforts
- Severity/Criticality – Typically for Bugs, but also used for other Issue types, the severity/criticality can help to inform as to urgency of need
- Customer Demand – Business and Customer needs (along with communicated timelines for delivery) can also dictate and inform timing
While the above information is useful for making educated decisions regarding the sequence of tactical work, these are discrete pieces of work that need to be prioritized and where the “art” often tips the scale over science.
Agile planning whether in slotting issues for Sprints or grooming the Kanban Ready for Development backlog rarely follows the strict order of priority as ranked in an organizations Agile Planning tool.
In an ideal world, the priority order would match the work order but we don’t live in an ideal world and Product Owners must deal with day to day decisions based on resource availability, blockers, and other intangible factors. If a UI developer frees up but the next priority is server heavy, the work assigned to the UI developer could be something much further down in the priority list based on the current situation.
This “Art” is something that is important to be able to make informed decisions, but yet not be bogged down with process or overly prescribed governance. There is a diminishing return to the amount of effort to analyze each and every Issue in a prioritization framework taking away the flexibility and the art of the Product Owner’s tactical decision making.
The Science of the Strategic Backlog
Planning for the Strategic Backlog however, requires a different level of rigor. This type of planning answers the question of “Are we even doing the right things for the organization?”.
Perfectly executed tactical planning without a strategic compass gets the organization nowhere fast.
A proper Strategic Backlog, while related, is quite different from the Tactical Backlog. For the Strategic view, a level of rigor, analysis and governance is absolutely critical to provide a framework for decision-making across the organizations.
Of course there is always an element of Art that also comes into play taking into consideration expert opinions and vision, however, for the Strategic Backlog, the science must rule.
To accomplish this and not interfere with the tactical planning and execution that is occurring in parallel, the planning must be raised up beyond Stories, Bugs, and refactorings to a higher level of the Agile hierarchy. Most often this is conducted at the Epic level within a specific Product Group.
Ensuring the Agile team is poised to deliver the best projects for the organization requires involvement beyond the Product development organization. The establishment of a Product Steering Committee or Investment Review Board can serve this purpose to help inform the Product Roadmap.
Here is a quick checklist to ensure your team is set up for success with your Steering Committee
Determine who across the organization needs to be involved
It’s a good idea to include input from the key organizations (Marketing, Sales, Customer Success, etc) as well as leadership, in order to get different viewpoints and perspectives.
The membership should be kept small with no more than 10 members who have voting authority to ensure that conversations are kept at an organizational strategic level and that conversations don’t devolve to individual wants and needs. The Steering Committee should be chaired by someone in the Product organization as ultimately it is the Product group that is accountable for delivery against the roadmap.
Determine an appropriate meeting cadence
Make sure this is done at the right time in your agile workflow/process and release rhythm. Typically, meeting at least once a month provides ample breathing room for decision making and feedback loop. Meetings should be 1-2 hours depending on the size of the group.
Determine a feeder strategy
Ideas for Epics to undertake need to be aligned to appropriate target markets and also must address specific pain points and needs for use cases within those target markets.
Steering Committees are often set up to have feeder groups to assess Target Market and Needs Analysis to come to the Steering Committee with Epics to consider. The makeup of the Steering Committee can be kept at a smaller manageable level by including other levels of the representative organizations in the feeder groups.
Collect Basic Epic and Budget Data
Proposed Epics do not need to be 100% figured out, but should have basic information by which to make strategic decisions. The Steering Committee decision process is not an account exercise but rather relies on the information and metadata provided by subject matter experts to assess and prioritize.
This can include basic descriptive information of the Epic but also must include basic elements of Value, Cost, Risk, and Balance in order to appropriately assess. “Costs” in the Agile world are often in terms of t-shirt sized hours or story point estimates in order to size the effort. Budget levels can be determined based on development team size (hours) or via historic performance (velocity).
Establish a Framework for Portfolio Decision making
This is perhaps the most critical step in the Strategic Backlog planning process.
There must be a repeatable methodology by which to compare possible paths. An ideal Steering Committee is run using Agile tools that will allow for real time analysis of a current Baseline (i.e. the currently approved path) as well as other possible deviations from that Baseline.
This includes an ability to visualize trade-offs of Value, Cost, Risk and Balance between possible paths to help the Steering Committee understand the implication of decisions. For Example:
- What if there are new disruptors we have to undertake? How do we react? What should slip?
- Are we doing all the most valuable Epics as soon as possible?
- Are we within budget for the next 3-6 months? If not, are we overrunning at an acceptable tolerance?
- Are we keeping our risk profile at an acceptable level?
- Are we balanced across the mix of projects we’d like to undertake?
Epic backlog planning software can assist with being able to manage the data, establish prioritization frameworks, and analyze/visualize trade-offs. Some can even use algorithms to suggest different possible paths depending on the target.
The Tactical and Strategic Cycle
The Steering Committee is the ultimate decision maker as to what Epics to go after with the full understanding of the trade-offs and implications of these decisions compared to other possible paths. It is at this point that the work around the Strategic Epic Backlog Planning transitions to actually getting the work done.
With the compass pointed in the right direction, the tactical execution then has deliberate purpose aligned to the organization’s strategic objectives. An archetype Agile planning ecosystem will provide an environment for the strategic decisions made by the Steering Committee to inform the Tactical. Approved Epic schedule, metadata, and prioritization information can flow to the tactical Agile management system to create the next level or hierarchy for underlying stories that make up the Epic. The feedback loop is complete as health and progress of the stories within epics continually informs the strategic Epic roadmap discussions.
By having next level Agile Roadmap Planning that seamlessly facilitates the Tactical and Strategic, it ultimately allows Product Owners to embrace both the art and science to successfully deliver the right features at the right time.
Do you have a similar question that needs addressing? We’d love to help you change the way you’re viewing your problem by incorporating Decision Lens methodologies! Please reach out to a member of the Decision Lens team today - we’d love to chat with you!
Want to build Roadmaps that deliver?
Let's get started
We have been modernizing public sector planning for 15+ years, evolving our solution to meet the needs of today while delivering the cutting-edge capabilities of tomorrow.
