One of the constant challenges for a product-based agile development team is to map what they are doing ‘right now’ to what the product is supposed to shape up to in say, 2-3 years from now.
It’s not about teams not knowing what they are working on but more about the fact that they may stay too focused on their day-to-day tasks, invariably undermining the sensitivity of the impact of their ‘present’ work in the big picture. The decisions or the choices made during execution today can have a big future impact, especially when the product is evolving.
Let’s take a real life example.
I was part of an agile team that was trying to introduce a text translation service for site content. The decision was made and a third-party machine translation tool was used. However, the product roadmap eventually mentioned that, in the future, users should be able to correct and provide their own contextual translation, which meant that the translation capability should have artificial intelligence so that it can learn on its own, based on feedback.
Given this development, the choice made was not apt and therefore required a fair degree of re-work because the big picture was not linked to what the agile team was tasked with in the sprint.
One can argue that teams can make a conscious effort to get this information, but the point is that why can’t these ‘long-term’ goals be captured in the existing agile tools and dashboards?
The agile teams execute well-defined and specific tasks in a development cycle but does that mean it must come at the cost of being indifferent to the product evolution? No, I don’t think so.
From what I know, there is no quick tool or framework that either advocates or recommends this information to the agile team, in their day-to-day functioning, but can such a view be created in the existing view? Worth a try? Let’s see how can we do it.
We will start with the most common artifact in agile – product backlog.
According to the SCRUM Institute, a product backlog is the list of things that needs to be done in a project. These things can include either enhancements and/or bugs. A numbered list isn’t helpful unless the team knows what the priority structure of the items are. This is where the Product Owner comes in who has the overall responsibility to work with the stakeholders to get clear requirements, resolve inter-dependencies, and get a prioritized list for the product backlog items.
It is possible that during this process, a larger and dependent work item is further broken down into small parts so that it is easy to develop for the team. These product backlog items are broken down into smaller chunks and executed in sprint cycles ranging from two to four weeks, answering the ‘how’ component of product development.
On the other hand, product backlog items are also mapped to the “true north” of the product often termed as the product vision. This is the desired state of the product that is often achieved through multiple version releases and links closely to what the target audience or customers want and the value it brings to them.
This chain of elements linking the agile team to customers (including product backlogs and vision) can be represented as:
Distant link between an agile team and what the customer needs…
With the lack of a view that clearly links sprints with the product vision, product owners often run into the risk of focusing too much on the ‘how’ part and lose sight of the larger and important goal of the ‘what,’ which can lead to misguided prioritization.
The approach I discuss here is to create a simple yet powerful view that links both the components. This is known as the Product Vision Matrix (PVM). The objective is to link the vision of the product to granular development items. This matrix becomes a key factor in analyzing the progress of the team with respect to product development. It also serves as a product dashboard for the senior management of the organization and keeps them posted about the attainability of the product goals.
As the name suggests, PVM is a matrix where the columns represent the dimensions (from micro to macro) that are being captured. Let’s understand PVM with the help of a food ordering app where the vision is to provide a food experience to the users, and the starting point is food ordering. The sample matrix looks like this:
|Product version||Big Rock Item||Feature||Sprint ID||Development Status|
|1.0 Beta||Ordering||Location-based||1.0_1||Development Complete|
|Cuisine-based||1.0_2||In Progress (Design)|
|Reviews||External ratings||1.0_1||Design Complete|
|Loyalty/Rewards||First order discounts||1.0_2||In Progress|
|1.0 Production||Ordering||Food truck orders||1.0_3||Planned|
|Orders from distant vendors (pack and deliver)||1.0_3||Planned|
|Loyalty/Rewards||Location-based real-time offers||1.0_4||Planned|
|2.0 Production||Ordering||Real-time tracking||2.0_1||YTB|
|3.0 Beta||Food Experiences||Food tours||TBD||YTB|
|Reviews||Reviews to be provided to external sites||TBD||YTB|
The Product Vision Matrix can have the following fields:
- Product version: This is the product version that is the official release milestone and is often what the customer receives.
- Big Rock Item: This is the category or theme that a feature belongs too. These items can also be the long-term product need areas of the product vision.
- Feature: This is the product feature that is being developed. The feature can belong to one or multiple themes (big rock items).
- Sprint ID: This is the sprint number in which a feature is being developed.
- Development status: This field denotes the progress of development (Planned, Design Complete, Development Complete, Tested, and Released).
Note that the structure of the matrix is indicative here. One can be more creative in identifying the columns that can capture the product vision.
The advantage of this approach is the clear visibility each team member has on the overall product goals. For an evolving product, team members should have a better understanding of the bigger picture. This not only allows them to contribute effectively but also enables them to take more accountability. The result is a more focused and adaptive team that always has a finger on the pulse of their customers and recognizes the difference their sprints can make in contributing to the vision and eventual success of the product.