Re: spikes used to gather business requirements
Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2 <at> emailchuck.com>
2012-02-01 04:26:05 GMT
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.
-------
Charles Bradley
http://www.ScrumCrazy.com
>________________________________
> From: Jean Richardson <jean <at> azuregate.net>
>To: scrumdevelopment <at> yahoogroups.com
>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.
>
>--- Jean
>
>From:scrumdevelopment <at> yahoogroups.com [mailto:scrumdevelopment <at> yahoogroups.com] On Behalf Of
Charles Bradley - Scrum Coach CSM PSM I
>Sent: Tuesday, January 31, 2012 4:14 PM
>To: scrumdevelopment <at> yahoogroups.com
>Subject: Re: [scrumdevelopment] spikes used to gather business requirements
>
>Jean,
>
>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
>
>-------
>Charles Bradley
>http://www.ScrumCrazy.com
>
>
>>
>>________________________________
>>
>>From:Jean Richardson <jean <at> azuregate.net>
>>To: scrumdevelopment <at> yahoogroups.com
>>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.
>>
>>---- Jean
>>
>>
>>
>>Jean Richardson
>>Azure Gate Consulting
>>~ Repatterning the Human Experience of Work
>>
>>AzureGate.net
>>(503) 788-8998
>>Jean <at> AzureGate.net
>>
>>
>>
>>
>>
>
>
>
>
>
RSS Feed