If you ignore the tool for a second, calling a "requirements gathering effort" a "User Story Spike", that is brought into a Sprint as a Product Backlog Item, is incorrect usage of the Product Backlog(and the Spike concept), IMO.
The intention of the Product Backlog is to indicate requirements for changes to the system under development, not to indicate a requirements gathering effort.
The intention of a spike story is to reduce a very large uncertainty in the estimate for turning a PBI into a feature, not the estimate uncertainty due to requirements gathering.
This is an example of the "Everything is a Story" Anti-Pattern(I consider it a Worst Practice), and I've found, in my experience, that this is a bad habit created by people who have a background in traditional Project Management. They take every "task" from a project plan and try to force fit it as a Story or Backlog Item, even when inappropriate.
In the new 2011 Scrum Guide, there is a shift in the backlog
development/grooming responsibilities. In the new guide, the PO can delegate the product backlog grooming leg work to the Development Team, though the PO remains responsible for the content of the backlog.
How would I handle this scenario?
What I'd really like to see, regardless of who is doing the leg work, is Weekly Team Product Backlog grooming, where the PO and Dev Team groom the backlog, and invite outside
stakeholders when necessary. If they're doing it at least weekly, then there should be little need for the team to track "requirements gathering efforts". On occasion, you may need a task defined here or there (that you can add to your Sprint Backlog if you like) to track down or investigate some particular requirement -- that's ok.
I've written a series of articles on Product Backlog Grooming that you can refer to for more detail.
From: Jean Richardson <jean@...>
Sent: Monday, January 30, 2012 11:25 AM
Subject: [scrumdevelopment] spikes used to gather business requirements
I am seeing a well known ALM vendor coaching teams in an
environment where I’m working coaching PO’s to drive spike stories into backlogs—a least this is how the customer interpreted the coaching. These spike stories are explicitly for the purpose of gathering business requirements. The PO is a proxy PO, BTW.
Anyone else seeing this odd move? It seems to me that this moves responsibility for accurate business requirements back into the Team and out of the PO role.
~ Repatterning the Human Experience of Work