- The Scrum Guide says, The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions,Message 1 of 209 , Jan 1, 2010View SourceThe Scrum Guide says, "The Product Backlog represents everything necessary to develop and launch a successful
product. It is a list of all features, functions, technologies, enhancements, and bug fixes that
constitute the changes that will be made to the product for future releases. Product Backlog
items have the attributes of a description, priority, and estimate. Priority is driven by risk, value,
and necessity. There are many techniques for assessing these attributes."
Based on that Dan is right with respect to what Scrum (aka Ken Schwaber) says should be on the Product Backlog.
Stories are not part of Scrum. They don't come from Scrum, but many Scrum teams use them. IIRC, Ken, err... Scrum says that Stories are one sort of thing that could be a backlog item.
Here's the problem: The term "Story" is shorthand for "User Story." User Stories have value to users. That is their defining characteristic. There is no such thing as a "Technical Story." It is a blatant abuse of the technique. Writing, "As a developer bla, bla, bla." Is just a waste of ink. It misses the point entirely. So, if you want to put technical stuff on your backlog you should find another way to capture it.
It happens that XP does this a slightly different way. In XP we write only User Stories to capture all of the things that the product should do. Then in cooperation with the customer we prioritize the User Stories. Then we work on the highest priority stories while doing all of the technical things we need to do to get them done.
That works pretty well, but it isn't Scrum, it is XP.
My advice is this: if you like User Stories do it the way XP suggests. If you want a comprehensive backlog that includes a lot of things that aren't User Stories then do us all a favor and don't call them stories and don't waste your time trying to kludge them into a form that makes them sound like they are in fact stories. Just because you can write "As a bla, I want to bla, so that bla" does not mean that you have a story. This email consists of words, but it is not a poem.
Technical infrastructure is not a user story. It is part of doing business, like keeping the lights on. You don't send your customers a bill for your lights, do you? (If you do, and they happen to pay it, please introduce me. I would like to have those customers as well.)
Bugs are not user stories. They are mistakes you made that you now have to fix. They do have value to the customer, but not making them in the first place would have even more customer value.
On Fri, Jan 1, 2010 at 3:33 PM, JackM <jack@...> wrote:
Agreed, all work that takes resources should be captured on the backlog. technical stories lay the foundation for the ultimate value the end user derives.
twitter.com/agilebuddy> dan@..., 425-269-8628
--- In email@example.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
> True. That's why (in my world) there are also analysis stories,
> infrastructure stories, etc... I believe in Jeff's notion that *all*
> work that is competing for priority needs to be on the Backlog - it's
> one of the main points of my CSM course. Not just work that provides
> user value, but all work that provides project value. It's a good
> discussion to have, though... how do we get such work prioritized and
> done? I use the Backlog, how do others do it? I'm sure there are many
> different strategies...
> Dan Rawsthorne, PhD, CST
> Senior Coach, Danube Technologies
> Ilja Preuï¿½ wrote:
> > Hi Klaus.
> > Technical user stories are an oxymoron.
> > Cheers, Ilja
- 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 alwaysMessage 209 of 209 , Jan 15, 2010View SourceOk, 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