Re: [scrumdevelopment] spikes used to gather business requirements
- Jean,You are certainly correct about my trademark. My hope is that I cover what was asked, plus a little surrounding information -- and I usually also add some commentary if I see other statements that concern me. There is only so much this email machine can do given the price of typing.Re: “have you all seen instances of this”I hope I was clear in that I have seen instances of this(my comment about "Everything is a Story"), so much so that I created a named Worst Practice for it that I talk about in my User Stories: Best and Worst Practices presentation (http://www.scrumcrazy.com/User+Stories+Best+and+Worst+Practices , it's the "Story == Project Task" bullet). It's a fairly common mistake IME. I give a lot of credit to Ron Jeffries for sharpening my understanding of User Stories.-------http://www.ScrumCrazy.com
From: Jean Richardson <jean@...>
Sent: Tuesday, January 31, 2012 5:46 PM
Subject: RE: [scrumdevelopment] spikes used to gather business requirements
Hi, Charles –Thanks for chiming in with such thoroughness as is your trademark. I’ve been working this issues IRL as well as on the list, and I think the relevant Team is going to get the clarifying help they need. There was a misunderstanding of the relevant vendor’s coaching.I’ve got to admit that I sometimes use this list as a reality check---like when I hear spikes being used to gather requirements and that sounds way out of left field to me. However, since I’m not actually an all-knowing goddess, no matter what some people think, I find it’s useful to reason things through in the context of a community which includes a number of skilled practitioners whom I respect.My original question went to “have you all seen instances of this” rather than “is this best Scrum practice.” Sometimes methodological adaptation moves initially in an unexpected direction, which was what I was checking in on with this handy online community of fellow threshers in the field.--- JeanJean,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.
- Why do Product Backlog Grooming?
- What does Product Backlog Grooming Look Like?
- Tips for Effective Backlog Grooming
http://www.ScrumCrazy.comFrom: Jean Richardson <jean@...>
Sent: Monday, January 30, 2012 11:25 AM
Subject: [scrumdevelopment] spikes used to gather business requirementsI 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.---- JeanJean RichardsonAzure Gate Consulting~ Repatterning the Human Experience of Work(503) 788-8998Jean@...