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 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 because 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.
Document the vision and linking it through to the 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 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.
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.
Putting the artefacts into a 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 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 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 backlog, 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.
Greenfield is simple and frankly you should ONLY be considering an agile approach because it provides early validation that your service works and there are customers who want…