The requirements sprint is a quick solution to challenges in receiving requirements from the product owner of a scrum-style project. It is also known as a Spike — an extended time of planning before the team commits to scope. The advantages are that the spike scope is entirely the responsibility of the product owner, not the scrum master or team. Therefore, the requirements are not rushed and hardline deferral of scope is avoided. The disadvantages are increased waste due to this interruption in development.
Before I decide to implement Spikes, I like to assess the complexity of the business processes and/or the solutions for possible root causes of waste. For example, the over-reaching to slightly expand the customer base and impress executives is a poor return on investment. The integration of an experimental single sign-on Web service is probably a poor option for a mission-critical release.
There may be a case for the requirements sprint or “Spike,” but first ask the tough questions. This is a test of your trust-building with key stakeholders, but it will give further-reaching good faith than simply adjusting your processes to accommodate fundamentally-flawed requirements.