A lot of focus and discussion in the Agile community is on Agile Teams and how they work and develop over time. I often find that how that work gets from the customer to the team is neglected or poorly understood. I would like to talk about this process and provide a framework for you and your organization to experiment with. I'll include some details but leave enough ambiguity for experimentation while you're creating a working framework.
Product Backlog Iceberg
The Product Backlog Flow framework has three conveyor belts of work flowing simultaneously and independently of each other to bring customer pains and problems to the Agile Teams to solve. These conveyor belts can be visualized using Mike Cohn's Product Backlog Iceberg shown below.
- Future Releases: Collection of feature epics encapsulating real customer problems we feel are worth solving. Feature epics in the Future Releases bucket have a Business Model Canvas with potential problem, solution, and customers identified but these may not yet be validated. Cost and revenue are roughly estimated. These feature epics may need go through an approval process before being considered for a Release. Rough feasibility will have been established with a technical Subject Matter Expert (SME) but detailed analysis of risks associated with implementation has yet to occur. The strategic and tactical business concerns are the prime focus while a feature epic rests in the Future Releases bucket. The number of feature epics in Future Release will generally match the company's product road map length. If the road map projects the next year then you would probably have a year’s worth of feature epics in Future Releases at a minimum.
- Release: Feature epics that are now tied to a specific release time frame. These feature epics would have been validated with customers and have acceptance criteria from the customer's POV. Feature epics in the Release bucket are reviewed and analysed by the Agile Team likely to implement the epic. The feature epic may be broken down to facilitate estimation or to isolate the riskier aspects of the feature. The desired outcome is for the Agile Team to confirm the feasibility of implementing the feature within a specific release window.
- Sprint: Sprint stories are generally very well understood by the Team and any outstanding technical or implementation questions have been answered through knowledge spikes and customer meetings. A team can target having few user stories that hold big surprises, i.e. issues the Team didn't know they didn't know. These stories meet the INVEST criteria, Independent, Negotiable, Valuable, Estimable, Small, and Testable.
These 3 flows are meant to operate independently and at all times but use Lean Just In Time (JIT) techniques. This means stories move from Future Releases to Release and from Release to Sprint at the last responsible moment. Try to not transition work up the iceberg too soon as features and epics have a finite Validity Runway. The Validity Runway is the time frame where Product/Market fit remains intact and the Product Owner and business feel the essence of a feature epic will not change. Due to the additional analysis work done in the Release and Sprint buckets, moving epics up the Product Backlog Iceberg too soon introduces the risk of re-work or wasted work if a feature epic is dropped for any reason,
Ideally, Agile Teams never stop sprinting. Work flows to them from the lower depths of the iceberg and each new feature epic introduced to the team during Product Backlog refinement (the act of adding detail, estimates, and order to items in the Product Backlog) could have its own goal and vision attached to it. This flow is possible because:
- Sustaining Innovation for existing products and customers keeps new features and feature enhancements flowing from customers to the Future Releases bucket.
- Set-up periodic customer interviews to get the latest problem(s) the customer is facing that you might be able to solve.
- Set targets for incoming sustaining innovation ideas based on product line or customer segments. These will eventually become part of the product road map and Future Release bucket.
- Establish a Business Model Canvas for each idea (Ash Maurya's Lean Canvas might be an excellent place to start). Identify and validate problem, solution, unique value proposition, and customers first.
- Move new feature and feature enhancement epics into the Future Release bucket once Problem/Solution fit is attained.
- Adjacent and Disruptive Innovation continuously occurs as Product Management, Sales, and Marketing are constantly looking for new product ideas and new markets for existing products.
- Establish a Business Model Canvas for each new idea.
- Use Eric Ries' Lean Start-up methodology to validate your new ideas and hypotheses.
- Timing for moving ideas into Future Release is contingent on how your company operates. The best scenario is for a small 'start-up' component within the company to take new ideas through Problem/Solution fit and begin establishing Product/Market fit before bringing these into the main production pipeline.
- Product Managers, Product Owners, and other business stakeholders will review the validity and priority of feature epics in the Future Releases, Release, and Sprint buckets to keep priorities up-to-date and keep the Business Models relevant.
- Use a Kanban board to manage and track all feature epics.
- Set-up the Work In Progress (WIP) number. This number sets the maximum amount of work that occupies a column. To do this, select a uniform means of measuring the feature epics. I would suggest Ideal Days as feature epics will generally be of varying sizes negating a strict counting of epics. It will take a little experimenting to get the WIP numbers that suit your company. The numbers will also be influenced by the number of Agile Teams available, the sizing of the effort on the feature cards, and the maturity of your Agile environment.
- Keep an open and running dialog with your customers, users, and potential customers from the initial problem inception through to implementation.
- Review the business value and priority of each feature epic in every column including the Sprint column. You would review those feature epics in the Sprint column because a feature can become obsolete at any time e.g. a feature may no longer be viable if competitive advantage is lost.
- Reorder feature epics on your Kanban board. Do not shy away from dropping a feature epic lower down the iceberg if business value and priority warrant it.
- Manage the expectations of your stakeholders. Inform all stakeholders of any changes in business value or priority, don't wait for them to 'discover' the changes.
- Problem solutions and the release cycle are disconnected
- Establish a predictable release cycle based on a realistic assessment of how fast this can be in your organization and how quickly your customers can take on new releases.
- All feature epics are prioritized.
- Keep your development teams focused on solving customer problems. Don't let your releases disrupt these teams. Avoid the waterfall trap of:
- Feature Complete date or Code Complete date,
- Development & QA test period, and
- Scrum Teams must deliver a 'potentially releasable' product at the end of each sprint. This must include any documentation (guides and such), marketing materials, etc.
- Reduce the chances of the development team discovering major 'unknowns' once a feature epic enters the Sprint bucket. As a general starting point, I would suggest that feature epics are broken down into sprint ready stories with the following attributes:
- Meets the conditions set in the INVEST acronym
- Enjoys a shared understanding by the Development Team with a measurable uncertainty of < 10% (i.e. fewer than 1 in 10 user stories hold any surprises)
- Has 3-5 Acceptance Criteria and Non-Functional Acceptance Criteria
- All UX definition work is complete, validated with the customer or customer proxy, and is ready for actual implementation
- Has an estimate using your team’s estimation technique and scoring mechanism
- Can be completed by the Development Team in 2-3 days
- Consider expanding your Feature Kanban board to include Problem Inception, Marketing, and Sales once the company is on-board with the continuous flow of customer problems from inception to post release.
ConclusionIn order to get the Agile Teams focusing on delivering the highest customer value in each sprint and delivering a ‘potentially releasable’ product at the end of the each sprint, the organization needs to switch their focus from Release Dates to Customer Value. This can be accomplished, arguably the hardest part, by getting the Agile Teams focused on Customer Value using the Product Backlog Flow process.
AcknowledgementsI'd like to explicitly thank the authors below for their pioneering research and studies.
- Mike Cohn, User Stories Applied: For Agile Software Development, available here
- Henrik Kniberg, engineering culture at Spotify, and
- Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, available here.