The Scrum Framework is not specifically prescribing when and how to test product hypothesis and perhaps that is one of the reasons why many teams and organizations out there are building entire products without incorporating stakeholders’ feedback.
The consequences of such practices could be severe as teams might build a product that is not serving stakeholders needs or not in the way stakeholders are expecting.
If the hypothesis validation could be completed before starting Sprints then the team is in a much better position to plan. A word of caution though, waiting for all hypothesis and assumptions to be validated before starting a single Spring might be the equivalent of working in phases and that would lead to waterfall development.
A more dynamic approach could be that the Product Owners validates assumptions a Sprint or two ahead of the of the Development Team. This validation with stakeholders could be done using paper prototypes (see page 47) or any other technique.
It’s important to mention that regarding of the technique or tools that used for this validation this is just a resemblance of the “real thing” that the team would be building. The corollary of this is that paper prototype should be good enough to provide insights and allow feedback but then the team will need to build the “real thing” as fast and as good as they can.
The Scrum Team should align its Spring Goal to deliver results to really test the assumptions, otherwise the Scrum Team might end up building something that looks great from a technical stand point but that is not contributing to validate hypothesis that were formulated based on stakeholder’s needs.
