Agile Product Backlogs – How to Transform your Vision

The only reason a delivery organisation exists is to create amazing products that delight and bring value to customers.

The reason a product exists and how value is derived from that product must be first set out in the agile product vision. The vision in-turn must flow through to the work of the agile delivery teams so they understand how they are contributing to the product.

Having clarity on how even the smallest piece of work relates back to the vision is motivational for teams. They can trace their piece of the puzzle back to the whole; it allows them to take pride in actively contributing to and progressing toward the organisation’s ultimate purpose.

All of this sounds obvious however, it amazes me how many organisations fail to connect their vision to the day-to-day work of their engineers.

In one organisation we helped recently, after a few days with the engineers I told the management team I could not work out what the team was trying to build, what the end goal was and therefore how much work was left to do. This caused consternation within the leadership team – they felt that what they wanted was clear but when I showed them the reality: work documented across spreadsheets, Jira and Confluence with no relationship to the vision and no ability to measure progress against a goal, they were shocked.

Documenting the agile product vision and linking it through to the agile backlog to give transparency and to enable teams to accurately measure their progress does not happen by luck. Implementing a clear method and structure from the start is vital.

The pyramid of scope: Tracing through to a well-structured agile product backlog

It is critical teams are able to deliver the vision in small, logical increments so that value is delivered quickly and feedback occurs in a short timeframe. This helps to maintain a low cost of change.

Given the need to link the work of the team to the organisation’s shared purpose, structured design is needed in the early stages. The pyramid of scope diagram below shows the relationships which bring structure and meaning to the work of teams.

 

1. The vision should be an inspirational paragraph articulating the problem we are trying to solve and why we are trying to solve it. It is the organisation’s ‘elevator pitch’ and should avoid jargon, acronyms and targets/measurements. If it doesn’t make you want to leap out of bed in the morning then it’s not right.
2. The ‘go to market’ strategy identifies the customers, market segment being targeted and goals of the product’s early public releases – the first few steps on the journey to the vision. The first release should cover the minimum functionality possible for a successful launch – the true definition of MVP.

An effective way to articulate the scope of the initial release is to write the press release you would issue at launch – an inherent part of the culture instilled by Jeff Bezos at Amazon.

It’s important to consider non-functional requirements at this point – being clear if, for example, it is possible to restrict the volume of users for the initial release as this will reduce complexity and thus time to market.

The ‘go to market’ strategy sets the early product roadmap, helping the team see beyond the first release and introducing a placeholder for features which can’t be delivered initially. The roadmap also helps prevent circular conversations with stakeholders about whether a feature is in the MVP or not because there is a place to put lower priority work.

1. Personas and User Journeys articulate the different groups of users, their goals, current pain points along with how the new service will solve their problems and create value for them. This ensures the agile product backlog is prioritised from the user perspective, ideally removing features which aren’t truly needed. User Journeys must be aligned with and deliver the goals of the ‘go to market’ strategy to maintain the link between the vision and what is actually prioritised and built.
2. Steel Threads. User Journeys tend to highlight important areas of scope i.e. key steps in the process, full delivery of each step would take a long time which in turn means waiting a long time for the initial release and most importantly for valuable feedback – that’s terrible, fast feedback is essential for agile delivery, it ensures we’re building the right product in the right way. Steel threads break user journeys into thin slices across the end to end process for rapid delivery by a single team. They start from a position of removing all of the ‘bells and whistles’ so that each step in the process is doing the absolutely minimum but can (and will) be extended later on.

You might need multiple threads to be finished before you can complete the first step of the ‘go to market’ strategy and release to the public, but they will form the core of your system and the backbone of any automated testing suite.

Putting the artefacts into an agile backlog

 

Where is the value?

Using the steel thread method helps to identify where true value lies. Identify the customers, the interactions and data that needs to flow in order to generate value – this is the foundation for high-level customer journeys.

Once you are clear where the value lies, the product backlog can be aligned so that even the most granular piece of work contributes towards the whole, helping each team see how they are contributing to the target.

Testing the backlog as it is created

How do we know the agile backlog will generate a valuable product? The truth is we can’t know until we start getting user feedback but, to help answer the question there are five tests I apply to a backlog and the artefacts within it:

1. Is the scope and value clear and testable?
2. Is the priority clear and in a single backlog?
3. Is it clear how teams will align to deliver the work so that it contributes to the vision?
4. How do we measure progress?
5. Are all delivery teams aligned on what “Done” means?

These tests are useful because even before the teams see the product backlog in agile, before a single line of code has been written, we can assess the quality of what they will build.

Working from the top of the scope pyramid down in order to structure your design and ultimately your backlog ensures teams are contributing to the whole and demonstrably delivers value while minimising dependencies.

Got questions about product backlogs, or want to discuss your agile vision? Get in touch here.

READ MORE

You might also be interested in these