Re: [!! SPAM] Re: Re: [scrumdevelopment] Re: User Stories business value and GWT
- I agree with what you say about Mike's discussion below. That is not a
reasonable story, assuming that the Product Owner doesn't doesn't think
it is. But I disagree that discussion of stories (as separate from user
stories) is nowhere in the literature. I have been discussing it at
conferences for more than five years, so there are instances out there.
And, when my book's finally done, there will be a discussion on the
concept out there. And, you're exactly right about the people that will
be confused. I wish to crisp up the language, not diffuse it. Words are
extremely important to me, and it is very confusing when you say that
the word "user" as a modifier isn't actually modifying anything... I
have a tough time watching stakeholders trying to describe how that
thing they want has actual "user" value, when it's actually value to
sales, or marketing, the team, or somebody else. It's sad... in my
experience the stakeholders either have to believe that "user" doesn't
actually mean anything, or that it means somebody other than the "user".
Confusing to my teams. Hence the word "story".
Anyway, just one more thing to argue about, like I said.
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
Adam Sroka wrote:
> Hi Dan:
> You are going to do what you do and call it what you call it. This is
> something I have discovered about you ;-) However, I really wish that
> you wouldn't use the term "story" to refer to things that the XP
> community and much of the Scrum community agree aren't stories. It
> does a disservice to the community by diluting the language. It is an
> example of what Martin Fowler calls Semantic Diffusion
> There is another audience here: the folks who haven't quite grokked
> what stories are and are trying to get it. They are the ones I am
> talking to.
> Nowhere in the literature does it talk about "kinds of stories" other
> than User Stories. Story is a shorthand for User Story.
> Mike Cohn wrote an entire book about User Stories. In it he says:
> "What you want to avoid are stories that are only valued by developers. For
> example, avoid stories like these:
> • All connections to the database are through a connection pool.
> • All error handling and logging is done through a set of common classes.
> As written, these stories are focused on the technology and the advantages to
> the programmers. It is very possible that the ideas behind these
> stories are good
> ones but they should instead be written so that the benefits to the customers or
> the user are apparent. This will allow the customer to intelligently prioritize
> these stories into the development schedule."
> I like that. It is a very nice way of saying what Ron, Ilja, George,
> I, and others have said in this thread.
> On Sat, Jan 2, 2010 at 12:58 AM, Dan Rawsthorne
> <dan.rawsthorne@...> wrote:
>> You're right. Only user stories have user value. Other kinds of stories
>> have other kinds of value. This language allows us to talk about things
>> that have other kinds of value, which is very cool, as well as allowing
>> us to use this new thing, the requirement/activity thing (called a
>> story) in our planning. We could call it an Item, I suppose, or a PBI,
>> but neither one of those has the same "promise for a conversation" and
>> all that stuff that comes along with a story. It's very nice to be able
>> to piggyback on existing knowledge, especially when the generalization
>> we're using is so obvious and natural.
>> As for trying to get "story" to mean "user story" - it's a little late
>> for that. Story has been used as the generalization for a long time. I
>> first used it 10 years ago, and I'm not the only one. The logic seems
>> pretty clear to people. The conversation usually starts off like this:
>> "user stories are stories that have user value, and there are other
>> kinds of stories, like analysis stories, infrastructure stories, and so
>> on..." and then we're off to the races. I think that most people realize
>> that if we wanted the word "story" to mean "user story", then why is the
>> word "user" in there? Of course, in XP environments, where user stories
>> are the only stories, it makes perfect linguistic sense that the word
>> "user" would be dropped for brevity. So, maybe it would be reasonable to
>> say that in an XP environment, the word "story" is shorthand for "user
>> story", but then I'd say "but I'm doing scrum, and that shorthand isn't
>> valid here, you'll have to be more specific..."
>> Just another one of the many little things we like to fight about, isn't
>> it? Part of the spice...
>> Dan Rawsthorne, PhD, CST
>> Senior Coach, Danube Technologies
>> dan@..., 425-269-8628
>> Adam Sroka wrote:
>>> On Fri, Jan 1, 2010 at 11:29 PM, Dan Rawsthorne
>>> <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
>>>> Adam, the form is not the story, either. I've been using the term
>>>> "analysis story" for over 10 years now, and actually got blessing from
>>>> Kent Beck to do that many years ago.
>>> Kent won't ever tell you not to do anything. If it's working for you
>>> it's a good thing. That's his style. Doesn't mean you get to change
>>> the definition of "story" for the rest of us.
>>> The way I look at it, the term
>>>> "User Story" means that it's a story that has User value. It could be in
>>>> connextra form (as a...) or not. What makes a story a brilliant thing is
>>>> that it is a request for something of value, is a promise for future
>>>> conversations, and contains both the request, the effort to achieve it,
>>>> and the def'n of done (as Ron puts it, card/conversation/confirmation).
>>>> I think as long as we say "user story" when we mean "user story" then we
>>>> should have no problems... but I don't like the term "technical story"
>>>> either, as it isn't telling me anything...
>>> Don't think I said anything that contradicted any of that. In fact, my
>>> first message on this thread was about the fact that I don't like the
>>> "connextra form" as you called it, because it allows people to think
>>> that things that don't have user value are stories since they can be
>>> kludged into the form.
>> To Post a message, send it to: scrumdevelopment@...
>> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
- Ok, so you were either spying on my teams, or this problem is WAY to
prevalent. I've been a manager of dev teams for a fairly long time now, and
I have always hated the phrase stretch goals. I ask my teams to set
realistic goals that I can count on. I'll do everything I can to help them
meet those goals. That was one of the reasons I got on the Agile bandwagon
to begin with. As teams become more comfortable, their velocity sometimes
does creep up a little. But more importantly, as they don't feel rushed to
just fill someone's arbitrary view of how much should get done, they produce
some really high quality stuff. They also feel more comfortable
experimenting with new things, and applying the creative aspect of the job,
not just the technical.
From: "Ron Jeffries" <ronjeffries@...>
Sent: Friday, January 15, 2010 8:34 AM
Subject: Re: [!! SPAM] Re: [scrumdevelopment] Re: User Stories business
value and GWT
> Hello, Steve. On Friday, January 15, 2010, at 10:09:33 AM, you
>> Sadly, what this group heard in that message was even more
>> destructive. They were consistently putting out 35 points, almost
>> like clockwork. They were consistently signing up for 40+ points,
>> because the "powers that be" wanted to see this sense of urgency.
>> This of course ended with a huge morale problem. "We never finish
>> our sprint. We never hit our target velocity. We must suck". Then
>> I go to the executive business review to explain "well they are
>> extremely consistent with their velocity, which is supposed to be
>> the goal. They don't hit the arbitrary signed up for velocity
>> because they are being pressured to do more work, rather than
>> maintain consistency."
> That just happened to Kate Oneal's team:
> Kate Oneal: Choosing the Stories
> After a failed iteration, the team regroups with a few new
> A pertinent quote, bowdlerized for the sensitive ears here:
> Jim said, “Yes. Think how bad things would have been if we didn’t
> keep the pressure on!”
> It seemed like the entire dev team snarled. Gil jumped up. “Damn
> it, you just set us up to fail! We tell you what we can accomplish
> and then you push us to do more. If we do the job right, we fail.
> If we do the job wrong, we ship crap. Stretch goals, my
> Everyone kind of fell back. Gil looked around, then said, “Well,
> sorry. But it’s crap. We can’t win. We can’t even tie.”
> Enjoy ...
> Ron Jeffries
> It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...! Groups Links