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.
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.
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.
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.
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.
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:
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.