When it comes to Sprint Reviews or demos, the golden rule is to show a working solution. You want to engage your audience in a way that elicits meaningful feedback. But what happens when your deliverable is something like a backend service or a software library? What if you don’t have have a visual front-end to show? It turns out, the approach you take depends largely on who your customers are.
1. When Your Customers are Developers
In scenarios where your customers are developers or other technical users who interact with your product through an API or a software library, demoing becomes a straightforward affair. These customers have the technical expertise to understand and appreciate the nuances of your work. You can directly showcase the functionalities of your API or library, enabling them to interact with it in real-time. This interaction not only makes the demo engaging but also allows you to gather specific, actionable feedback. Developers can provide insights based on their experience with similar tools, suggest enhancements, or identify potential issues—feedback that is gold for refining and improving your product.
2. When Your Customers are End-Users
The challenge intensifies when your end product or service is meant for end-users who do not interact with the backend directly. In such cases, presenting a backend feature in isolation doesn’t translate to meaningful feedback from these customers. It’s like presenting the average car buyer with an improved brake pad design and asking for feedback. We cannot expect meaningful feedback. We can only expect valuable end-user feedback on the end-to-end experience—how the product or service affects their interaction with the front-end.
This is where the importance of building features in smaller, complete, end-to-end increments comes into play. Instead of building one complete backend service, build just a part of it together with a part of the frontend. By adopting this approach, you ensure that each demo has a tangible aspect that end-users can see, interact with, and provide feedback on.
This methodology not only keeps your development agile but also minimizes investment risk by ensuring that feedback is continuously integrated into the development process, avoiding long periods of development without user input.
Building End-to-End: A Necessity for Meaningful Feedback
For products and services where the customer interaction is primarily with the front-end, the inability to provide an end-to-end demo can lead you to operate without valuable customer feedback. This approach increases the risk of developing features that may not align with user expectations or needs, thus escalating investment risks and potentially leading to costly pivots down the line.
What About Internal Demos?
It’s worth mentioning that, in some scenarios, you might find value in demoing backend work internally to other teams within your organization, particularly when they’re tasked with developing the frontend or other components that interact with your backend services or libraries.
This internal demoing fosters collaboration and alignment but comes with its own set of trade-offs. Opting for this route means extending the period before receiving direct feedback from the end-users, essentially flying blind. This delay in user feedback can impact your agility and elevate investment risks. It’s a trade-off. You must weigh these considerations against your specific constraints and goals, making a deliberate choice in the pursuit of developing products that truly meet user expectations.
Conclusion
The essence of agile development and successful demos lies in the ability to iterate rapidly based on user feedback. When dealing with backend services or software libraries, understanding your audience is crucial.
For technical users, direct interaction with the backend components can suffice. However, for end-users, encapsulating backend developments within a complete, end-to-end feature that they can interact with becomes essential. This strategic approach not only enhances the relevance of the feedback received but also ensures that development efforts are always aligned with user needs and expectations. It therefore maintains agility and reduces investment risk.