Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] We have a couple of Developer and tester positions open and are looking for ones that have strong XP experience

Expand Messages
  • Joshua Kerievsky
    Colleen, A lot of quality programmers attend local XP/Agile/Patterns groups. You could talk to the leader of such a group about chatting with the programmers
    Message 1 of 2 , Feb 25, 2003
    • 0 Attachment
      Colleen,

      A lot of quality programmers attend local XP/Agile/Patterns groups. You
      could talk to the leader of such a group about chatting with the programmers
      after one of their meetings. You might also consider attending the 1st
      Agile Development Conference (http://www.agiledevelopmentconference.com),
      which us taking place in your city.

      When I ran a patterns study group in New York City, recruiters would often
      want to meet people from our group -- I'd suggest that they come when the
      group's session ended and we headed for our favorite bar/restaurant. I
      found it relaxing and interesting to talk to a recruiter in a bar/restaurant
      (as opposed to on the phone, during work hours) and I sure didn't mind when
      they bought a few rounds of drinks.

      best regards
      jk

      I n d u s t r i a l L o g i c , I n c .
      Joshua Kerievsky
      Founder, Extreme Programmer & Coach
      http://industriallogic.com
      866-540-8336 (toll free)
      510-540-8336 (phone)
      Berkeley, California

      ----- Original Message -----
      From: "Mammone, Colleen" <colleen.mammone@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Tuesday, February 25, 2003 12:01 PM
      Subject: [XP] We have a couple of Developer and tester positions open and
      are looking for ones that have strong XP experience


      > Hi,
      > I'm hoping you guys can steer me in the right direction.
      > I work for LANDesk Software in Salt Lake City Utah, and we have a couple
      > of Software developer positions we are trying to fill.
      > We have gone the conventional recruiting route and seem to be coming up
      > a bit short on what we would like in the next candidate(s) we hire.
      > Of course we want developers with strong object oriented programming
      > skills (preferably C# or C++), but we are also looking for motivated,
      > positive, teamplayers. Someone who will come in and immediately
      > contribute not only to our efforts to implement the XP principles, but
      > also to the quality of the code we are producing.
      > We also have a couple of postitions for Testers with very strong test
      > automation skills, along with the XP and team oriented skills as well.
      >
      > My question to this group is, where is the best place for me to look for
      > these people? Monster.com, typical software development recruiters, and
      > word of mouth have not produced the caliber of person we are hoping for.
      >
      > Any suggestions would be greatly appreciated.
      > Thanks
      >
      > Colleen Mammone
      > LDMS Engineering Project Manager
      > (801) 369-2003 Cell
      >
      >
      >
      >
      > -----Original Message-----
      > From: extremeprogramming@yahoogroups.com
      > [mailto:extremeprogramming@yahoogroups.com]
      > Sent: Tuesday, February 25, 2003 11:29 AM
      > To: extremeprogramming@yahoogroups.com
      > Subject: [XP] Digest Number 3151
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > ------------------------------------------------------------------------
      >
      > There are 25 messages in this issue.
      >
      > Topics in this digest:
      >
      > 1. Re: Velocity & Yesterday's weather
      > From: wecaputo@...
      > 2. Development steering
      > From: Ralph Johnson <johnson@...>
      > 3. Re: XP Stories and UML Use Cases
      > From: Piergiuliano Bossi <P.Bossi@...>
      > 4. Re: Re: How to write stories for bugs?
      > From: Ron Jeffries <ronjeffries@...>
      > 5. Re: Writing User Stories
      > From: Nicholas Robinson <nicholasrobinson@...>
      > 6. New file uploaded to extremeprogramming
      > From: extremeprogramming
      > 7. Re: Writing User Stories
      > From: Steve Berczuk <berczuk@...>
      > 8. Re: Writing User Stories
      > From: "Jeff Nielsen" <jeff.nielsen@...>
      > 9. Re: How to write stories for bugs? (and mice ;-)
      > From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      > 10. SPAM: New file uploaded to extremeprogramming on 2/25 -- exam
      > cert. products
      > From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      > 11. Re: Writing User Stories
      > From: Ron Jeffries <ronjeffries@...>
      > 12. Re: Re: How to write stories for bugs? (and mice ;-)
      > From: Ron Jeffries <ronjeffries@...>
      > 13. RE: Re: How to write stories for bugs?
      > From: "Van Hamersveld, Mark" <mvanhame@...>
      > 14. RE: Velocity & Yesterday's weather
      > From: "Dubbs, Roger" <rdubbs@...>
      > 15. RE: Re: How to write stories for bugs?
      > From: "Tim Moore" <tmoore@...>
      > 16. RE: Re: How to write stories for bugs?
      > From: "Tom Copeland" <tom@...>
      > 17. RE: Re: How to write stories for bugs?
      > From: "Tim Moore" <tmoore@...>
      > 18. Re: Re: How to write stories for bugs?
      > From: "David Putman \(DavidPutman.com\)"
      > <davidputman@...>
      > 19. Re: Re: How to write stories for bugs?
      > From: Edmund Schweppe <schweppe@...>
      > 20. RE: Re: How to write stories for bugs?
      > From: "Van Hamersveld, Mark" <mvanhame@...>
      > 21. Re: Re: How to write stories for bugs?
      > From: Brad Appleton <brad@...>
      > 22. Re: Velocity & Yesterday's weather
      > From: "Kiel Hodges <kielhodges@...>"
      > <kielhodges@...>
      > 23. RE: Writing User Stories
      > From: "Dan Rawsthorne" <DrDan@...>
      > 24. Re: How to write stories for bugs?
      > From: "Kiel Hodges <kielhodges@...>"
      > <kielhodges@...>
      > 25. RE: Re: How to write stories for bugs?
      > From: wecaputo@...
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 1
      > Date: Tue, 25 Feb 2003 00:47:09 -0500
      > From: wecaputo@...
      > Subject: Re: Velocity & Yesterday's weather
      >
      >
      > Ryan:
      > >The statistical number crunching of previous iterations can provide a
      > good
      > >base line, but I dont think you can ever beat having the developers sit
      > >down, evaluate the tasks, and give an estimate of what can be done in a
      > >given iteration...
      >
      > As I mentioned in another post in this thread, Yesterday's Weather (YW)
      > is
      > only one part of XP's adaptive planning approach. Two other important
      > factors are estimates being adjusted regularly based on what we learn
      > doing
      > stories, and good old common sense. YW isn't a rule, its a tool -- one
      > of
      > many that XP teams use. We get good at doing it via practice and
      > refinement, just like all tools. I use a lot of tools to do my job, if
      > they
      > aren't helping me, I change them, adjust them, or discard them as suits
      > my
      > needs.
      >
      > My suggestion to others is that they use the tools of XP the same way --
      > not as blind rules, or rough hammers that will somehow make all of our
      > problems go away, but as tools that we might get some good use out of if
      > we
      > practice with them, and try to learn how people are using them. That's
      > one
      > reason I listen here: to see what others are learning about the XP
      > toolbox
      > from repeated use.
      >
      > Best,
      > Bill
      >
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 2
      > Date: Tue, 25 Feb 2003 00:47:19 -0600 (CST)
      > From: Ralph Johnson <johnson@...>
      > Subject: Development steering
      >
      > An earlier message expressed a worry that if development pointed
      > out potential problems, they might end up steering the project.
      >
      > I had a guy build a shed in my back yard. I had bought a
      > "shed kit" and decided to spend a few hundred dollars to
      > have someone else put it together, and was glad I did.
      > This was about shed 1000 for him. He told me that in the
      > winter, heavy snow would make the sides bow out, but he
      > could put in a cross-brace to keep it from happening.
      > He also said that door had a tendency to swing loose, and
      > that he could put a crude latch on it to keep that from
      > happening. I was glad to pay a little extra for those
      > things, but would have been annoyed if he had just gone
      > ahead and done them.
      >
      > I like car mechanics who look around and notice things and
      > ask me if I want them to work on them. I hate car mechanics
      > who fix lots of things and then bill me without any warning.
      >
      > The customer must steer, but a good developer will not
      > hesitate to point out potential problems and suggest better
      > ways of doing things. Communication is vital!
      >
      > -Ralph Johnson
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 3
      > Date: Mon, 24 Feb 2003 22:47:06 +0100
      > From: Piergiuliano Bossi <P.Bossi@...>
      > Subject: Re: XP Stories and UML Use Cases
      >
      > Yaron,
      >
      > attachments are stripped away. You can try to explain yourself a
      > little-bit more or
      > upload the file somewhere.
      >
      > Ciao, Giuliano
      >
      > PS: my wife loves Kinder eggs, I personally prefer Nutella much more
      > even if there are no surprises at all... :-)
      >
      > Rosenbaum Yaron wrote:
      >
      > > Ok, let me try to explain myself.
      > >
      > > Take a look at the excel I attached.
      > > It's just a user story, with more details. It's an engineering task,
      > and a
      > > story, and a sequence diagram.
      > > It's almost like a Kinder egg. :-)
      > >
      > > Yaron Rosenbaum
      > > Chief Software Engineer
      > > CAP Project
      > > Comverse
      > >
      > > +972-3-7663411
      > > yaronr@...
      > >
      > > -----Original Message-----
      > > From: Piergiuliano Bossi [mailto:P.Bossi@...]
      > > Sent: Friday, February 21, 2003 12:43 AM
      > > To: extremeprogramming@yahoogroups.com
      > > Subject: Re: [XP] XP Stories and UML Use Cases
      > >
      > > Rosenbaum Yaron wrote:
      > >
      > > > Stories are imprecise, and hard to track over time.
      > >
      > > I guess that I'm not saying anything really original if I tell you
      > that:
      > > *) yes, sometimes stories are imprecise, but acceptance tests normally
      > are
      > > really precise
      > > *) it is really easy to track stories over time, we did it down to a
      > > precision of 30' actual work and I know several teams that did it
      > > successfully too
      > >
      > > Or did you mean to say that is hard to track their **changes** over
      > time?
      > >
      > > Yes, that is hard, but splitting is a useful tool and tracking a split
      > is
      > > not difficult. Is this the aspect that you need to track it? If so,
      > why?
      > >
      > > Ciao,
      > > Giuliano
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 4
      > Date: Tue, 25 Feb 2003 02:46:59 -0500
      > From: Ron Jeffries <ronjeffries@...>
      > Subject: Re: Re: How to write stories for bugs?
      >
      > On Monday, February 24, 2003, at 10:37:15 PM, Edmund Schweppe wrote:
      >
      > > Ron Jeffries wrote:
      > >> On Monday, February 24, 2003, at 6:29:46 PM, Edmund Schweppe wrote:
      > >> > Regardless of the client's level of knowledge, the memory leak is
      > still
      > >> > a defect. For a particular application, the Customer may not care -
      > or
      > >> > may care more about other defects - but it's still a defect.
      > >> Yes. And if it is, then there needs to be a customer test that shows
      > that
      > >> there is no such defect. The customer job isn't done until there are
      > tests
      > >> for everything important.
      >
      > > Is it still a defect if the Customer doesn't think it's important
      > enough
      > > to have a test and get it fixed? I think so - an unimportant defect,
      > but
      > > a defect none the less. Of course, other folks' mileage may vary.
      >
      > Sure. And still it needs to go through the customer, because (in XP)
      > only
      > the customer can decide.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > It's easier to act your way into a new way of thinking
      > than to think your way into a new way of acting. --Millard Fuller
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 5
      > Date: Tue, 25 Feb 2003 08:14:23 +0000 (GMT)
      > From: Nicholas Robinson <nicholasrobinson@...>
      > Subject: Re: Writing User Stories
      >
      > Hi Jeff,
      >
      > Thanks for that. When we think of use cases, we sit down and consider
      > what the goals of the user
      > is. He wants to make a payment, make an order, track an order. Is this
      > the same granularity as
      > the user story, but in a less formal format? Is a story broken down into
      > task cards? I need to
      > re-read some of the Kent Beck stuff, but any practical guidance is most
      > appreciated.
      >
      > Regards
      >
      > Nick.
      > --- Jeff Nielsen <jeff.nielsen@...> wrote: > From the
      > green book (Planning XP):
      > >
      > > "A user story is a chunk of functionality that is of value to the
      > customer."
      > >
      > > It provides a simple way for developers and customers to partition
      > what the
      > > system needs to do so that it can be delivered in pieces.
      > > A story must be:
      > >
      > > 1.1. Understandable to customer/developer
      > > 2.2. Testable
      > > 3. 3.Valuable to the customer
      > > 4. Small enough to build a few each iteration
      > > -
      > >
      > > These four criteria have helped me keep people on track who are new to
      > > deciding "what is a story".
      > >
      > > Jeff Nielsen
      > > Digital Focus (www.digitalfocus.com)
      > >
      > > ----- Original Message -----
      > > From: <nicholasrobinson@...>
      > > To: <extremeprogramming@yahoogroups.com>
      > > Sent: Monday, February 24, 2003 10:58 AM
      > > Subject: [XP] Writing User Stories
      > >
      > >
      > > > Hi,
      > > >
      > > > I have two books on XP, and both dont seem to explain fully what a
      > > > User Story is. Can someone either explain to me, as if I know only
      > > > of Use Cases, or maybe point me to a link? I need to swot up on them
      > > > because on Wednesday the XP Workshop I am in is gonig to start
      > > > producing the requirements for the two projects we have decided to
      > > > build applying XP. Nobody as yet, knows 100% how to write User
      > > > Stories or how to plan, so any pointers to any good online resources
      > > > would be most welcome.
      > > >
      > > > Thanks,
      > > >
      > > > Nick.
      > > >
      > > >
      > > >
      > > > To Post a message, send it to: extremeprogramming@...
      > > >
      > > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > > >
      > > > ad-free courtesy of objectmentor.com
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > >
      > >
      >
      > __________________________________________________
      > Do You Yahoo!?
      > Everything you'll ever need on one web page
      > from News and Sport to Email and Music Charts
      > http://uk.my.yahoo.com
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 6
      > Date: 25 Feb 2003 09:05:16 -0000
      > From: extremeprogramming
      > Subject: New file uploaded to extremeprogramming
      >
      >
      > Hello,
      >
      > This email message is a notification to let you know that
      > a file has been uploaded to the Files area of the extremeprogramming
      > group.
      >
      > File : /000000000_www_passiteasy_com_usd10_all
      > _IT_Exam_Certs.txt
      > Uploaded by : passiteasy_com4 <passiteasy_com4@...>
      > Description : RE: www.passiteasy.com usd$10 all IT Exam Certs
      >
      > You can access this file at the URL
      >
      > http://groups.yahoo.com/group/extremeprogramming/files/000000000_www_pas
      > siteasy_com_usd10_all%20_IT_Exam_Certs.txt
      >
      > To learn more about file sharing for your group, please visit
      >
      > http://help.yahoo.com/help/us/groups/files
      >
      > Regards,
      >
      > passiteasy_com4 <passiteasy_com4@...>
      >
      >
      >
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 7
      > Date: Tue, 25 Feb 2003 08:39:15 -0500
      > From: Steve Berczuk <berczuk@...>
      > Subject: Re: Writing User Stories
      >
      > Nicholas Robinson wrote:
      > > Thanks for that. When we think of use cases, we sit down and consider
      > what the goals of the user
      > > is. He wants to make a payment, make an order, track an order. Is
      > this the same granularity as
      > > the user story, but in a less formal format? Is a story broken down
      > into task cards? I need to
      > > re-read some of the Kent Beck stuff, but any practical guidance is
      > most appreciated.
      >
      > My thinking about this is that the goal is to communicate with the
      > customer about what they want the system to do. I get frustrated when a
      > group spends a lot of time arguing about what is/is not a {story, use
      > case, scenario, (the word someone else proposed earlier in this
      > thread)}. The real question is "do you understand what to build?"
      > Stories (in the sense of XP, or in the sense of "once upon a time") are
      > good because they are concepts that a customer should be able to
      > understand.
      >
      > Admittedly, at some point you (the developer) may want to work with the
      > customer to refine the story so that you can build it, but the key
      > things are that a story:
      > - maps to something that you can schedule in an iteration
      > - is testable
      > - (maybe one or two more things)
      >
      > Depending on your customer, you may have more details. I suspect that if
      >
      > your customer is someone who is using APIs for a library you are
      > writing, your story may be more like a use case. If your customer is a
      > baker (to pick an example from a recent post) it will be more narrative.
      >
      > This is based on my experience.... YMMV.
      >
      > -Steve
      >
      >
      > --
      > Steve Berczuk | steve@... | http://www.berczuk.com
      > SCM Patterns: Effective Teamwork, Practical Integration
      > www.scmpatterns.com
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 8
      > Date: Tue, 25 Feb 2003 08:26:08 -0500
      > From: "Jeff Nielsen" <jeff.nielsen@...>
      > Subject: Re: Writing User Stories
      >
      > From: "Nicholas Robinson" wrote
      >
      > > Thanks for that. When we think of use cases, we sit down and consider
      > what the goals of the user
      > > is. He wants to make a payment, make an order, track an order. Is
      > this
      > the same granularity as
      > > the user story, but in a less formal format? Is a story broken down
      > into
      > task cards? I need to
      > > re-read some of the Kent Beck stuff, but any practical guidance is
      > most
      > appreciated.
      >
      > The stories are expressed in language that the customer can understand.
      > Another word for story is "feature". The stories are used for
      > high-level
      > planning (i.e., deciding what gets built each iteration, understanding
      > how
      > long it will take until enough features are implemented to release).
      >
      > When it comes time to build each story, the developers get the detailed
      > requirements from the customer (preferably in the form of acceptance
      > test
      > cases), and break it down into technical tasks. The tasks are all of
      > the
      > things that the developers need to do to implement the story. Tasks are
      > used for detail-level planning.
      >
      > You *really* need to read the green book, especially if you're going to
      > try
      > to do XP-style project management.
      >
      > Jeff
      >
      >
      > > --- Jeff Nielsen <jeff.nielsen@...> wrote: > From the
      > green
      > book (Planning XP):
      > > >
      > > > "A user story is a chunk of functionality that is of value to the
      > customer."
      > > >
      > > > It provides a simple way for developers and customers to partition
      > what
      > the
      > > > system needs to do so that it can be delivered in pieces.
      > > > A story must be:
      > > >
      > > > 1.1. Understandable to customer/developer
      > > > 2.2. Testable
      > > > 3. 3.Valuable to the customer
      > > > 4. Small enough to build a few each iteration
      > > > -
      > > >
      > > > These four criteria have helped me keep people on track who are new
      > to
      > > > deciding "what is a story".
      > > >
      > > > Jeff Nielsen
      > > > Digital Focus (www.digitalfocus.com)
      > > >
      > > > ----- Original Message -----
      > > > From: <nicholasrobinson@...>
      > > > To: <extremeprogramming@yahoogroups.com>
      > > > Sent: Monday, February 24, 2003 10:58 AM
      > > > Subject: [XP] Writing User Stories
      > > >
      > > >
      > > > > Hi,
      > > > >
      > > > > I have two books on XP, and both dont seem to explain fully what a
      > > > > User Story is. Can someone either explain to me, as if I know
      > only
      > > > > of Use Cases, or maybe point me to a link? I need to swot up on
      > them
      > > > > because on Wednesday the XP Workshop I am in is gonig to start
      > > > > producing the requirements for the two projects we have decided to
      > > > > build applying XP. Nobody as yet, knows 100% how to write User
      > > > > Stories or how to plan, so any pointers to any good online
      > resources
      > > > > would be most welcome.
      > > > >
      > > > > Thanks,
      > > > >
      > > > > Nick.
      > > > >
      > > > >
      > > > >
      > > > > To Post a message, send it to: extremeprogramming@...
      > > > >
      > > > > To Unsubscribe, send a blank message to:
      > > > extremeprogramming-unsubscribe@...
      > > > >
      > > > > ad-free courtesy of objectmentor.com
      > > > >
      > > > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > > > >
      > > > >
      > > >
      > > >
      > > > To Post a message, send it to: extremeprogramming@...
      > > >
      > > > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      > > >
      > > > ad-free courtesy of objectmentor.com
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > >
      > > __________________________________________________
      > > Do You Yahoo!?
      > > Everything you'll ever need on one web page
      > > from News and Sport to Email and Music Charts
      > > http://uk.my.yahoo.com
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > >
      > >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 9
      > Date: Tue, 25 Feb 2003 13:47:49 -0000
      > From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      > Subject: Re: How to write stories for bugs? (and mice ;-)
      >
      > > Edmund Schweppe wrote:
      > >> If the Customer is sufficiently technically savvy, they'll
      > >> know to ask about memory leaks; if not, [...]
      >
      > Or they'll quite rationally assume that the programmers are
      > technically savvy enough to know that memory leaks are a bad thing,
      > and should be avoided.
      >
      > >> Regardless of the client's level of knowledge, the memory
      > >> leak is still a defect. For a particular application, the
      > >> Customer may not care - or may care more about other
      > >> defects - but it's still a defect.
      >
      > --- Ron Jeffries <ronjeffries@a...> wrote:
      > > [...] And I certainly think that memory leaks are a defect and
      > > usually an important one.
      >
      > A memory leak is a defect. It's a waste of resources and a violation
      > of standards. But the priority of fixing it, relative to other
      > business needs *IS* open to interpretation.
      >
      > I wrote a small C++ program some years ago that leaked memory quite
      > profusely. This was intentional: It was a quick and dirty prototype
      > used to demonstrate that certain kinds of expression parsing could be
      > done. The production code would be written in PL/I, with no memory
      > leaks.
      >
      > For a long running program, typically a service on a server, memory
      > leaks can be a big problem. For a program that runs and exits, the
      > most effective way to free memory can be to exit the program,
      > terminating the process. I'm serious. It's true.
      >
      > The decision as to when The Customer's time and money should be spent
      > to improve the efficiency with which the program uses system
      > resources is The Customer's. Let's allow the customer to make
      > business decisions regarding their investment.
      >
      >
      >
      >
      >
      > > Edmund Schweppe wrote:
      > >> [1] I remember one project in particular that I worked on,
      > >> where the end users were grocery store bakery managers.
      > >> During our first design session, one of them pointed to the
      > >> mouse and asked me what that white thing was.
      >
      > I remember, in the late 1980's, when a top level manager of a major
      > international computer company asked about the "rat" on the Sun
      > workstation we were using in a demo. He had forgotten that we
      > referred to that little rodent as a "mouse." ;->
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 10
      > Date: Tue, 25 Feb 2003 13:51:51 -0000
      > From: "jeffgrigg63132 <jgrigg@...>" <jgrigg@...>
      > Subject: SPAM: New file uploaded to extremeprogramming on 2/25 -- exam
      > cert. products
      >
      > SPAM:
      >
      > > File : /000000000_www_passiteasy_com_usd10_all
      > _IT_Exam_Certs.txt
      > > Uploaded by : passiteasy_com4 <passiteasy_com4@y...>
      > > Description : RE: www.passiteasy.com usd$10 all IT Exam Certs
      > >
      > > You can access this file at the URL
      > >
      > http://groups.yahoo.com/group/extremeprogramming/files/000000000_www_p
      > assiteasy_com_usd10_all%20_IT_Exam_Certs.txt
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 11
      > Date: Tue, 25 Feb 2003 09:04:19 -0500
      > From: Ron Jeffries <ronjeffries@...>
      > Subject: Re: Writing User Stories
      >
      > On Tuesday, February 25, 2003, at 3:14:23 AM, Nicholas Robinson wrote:
      >
      > > Thanks for that. When we think of use cases, we sit down and consider
      > what the goals of the user
      > > is. He wants to make a payment, make an order, track an order. Is
      > this the same granularity as
      > > the user story, but in a less formal format? Is a story broken down
      > into task cards? I need to
      > > re-read some of the Kent Beck stuff, but any practical guidance is
      > most appreciated.
      >
      > Card, Conversation, Confirmation:
      >
      > +-Card------------+
      > | Make a Payment. |
      > +-----------------+
      >
      > Conversation:
      >
      > Customer: (Showing above story card.) We need to make a payment.
      > Programmer: (Grabbing blank cards for notes.) OK, what's that mean?
      > C: The user has an account balance.
      > P: Yes.
      > C: The user has a credit card and wants to use it to pay some of the
      > balance.
      > P: Can he pay it some other way?
      > C: Later on we will accept direct bank transfers.
      > P: Maybe we should call this story "Make a Payment with Credit Card",
      > but that's up to you.
      > C: OK, let's do that. (scribbles on card)
      > So anyway, we want to get the customer's credit card number,
      > expiration, and the CC code, and transmit a payment to Visa.
      > P: What's a CC code?
      > C: (takes out credit card) It's this printed number on the card. It
      > doesn't show up on paper prints of the card, so it is a bit of a
      > security thing to make the user type it in.
      > P: Are we going to require the number always?
      > C: Probably. There are two ways to transmit a charge to Visa. But
      > we're not
      > sure if we'll do non-CC or not.
      > P: You've mentioned Visa twice. Are we going to just use Visa?
      > C: No. Visa, MasterCharge, and a few lesser cards all go through the
      > same
      > clearing with the same transactions. Later we will do some other
      > cards
      > like AmEx that use separate clearing. That will be another story.
      > P: But the basic kind of operation will be the same, right? We get the
      > card info and pass it to the card people and they say go or no?
      > C: Right.
      > P: You didn't mention an amount. Do we always pay off the total
      > balance?
      > C: No, we got off on the CC code. The user also enters the balance
      > amount
      > that he wants to pay.
      > P: So we send that proposed transaction to the credit card company,
      > and
      > they authorize or deny.
      > C: Right. Then we display a results page to the user.
      > P: OK, I get the idea. We'll need to know how to transmit and receive
      > messages to the credit card company.
      > C: Yes. Here is their writeup of how to connect to their web service,
      > and
      > the format of the XML messages. (hands copy to programmer)
      > P: We haven't done any web services connections yet, we'll have to
      > experiment a little. Couple of days, probably, before we can give
      > you a
      > good estimate on the whole story. Sounds like the rest is a couple
      > of
      > standard web forms.
      > C: Right.
      > P: Do we verify the CC number separately, or as part of the main
      > transaction?
      > C: Part of the main. Otherwise someone could sit on the web page and
      > try
      > different CC numbers until he found it.
      > P: Gotcha. I think that's enough for us to shape in most of the code
      > and
      > a mock up page format. Unless you have a sketch of what it should
      > look
      > like?
      > C: I was thinking like this. (Draws something on a card.)
      > P: (takes card) OK, we'll start from this. You can tune it after you
      > see
      > it. I'll assume two days to fiddle the form back and forth during
      > the
      > iteration. That's about what it took for the order form.
      > C: OK, what else?
      > P: How are you going to test this?
      > C: I'd like two things. First of all, I want to put the system in a
      > mode
      > where transactions are verified against an internal file that I
      > control, listing account number, balance, card, CC, and like that,
      > and
      > you implement something that sends the XML to a program that uses
      > that
      > file. That way once we get that going we can set up accounts and
      > play
      > with them.
      > P: We can do that. Once we figure out Web Services we can estimate
      > that
      > better. Do you want that to be a web service?
      > C: I don't care, whatever works best. I'd say do it without Web
      > Service
      > at first, won't it be faster?
      > P: Yes, both to build and to run. We'll probably need at least one
      > test
      > on your side or ours of actual Web Services working as well. But
      > you
      > said there were two kinds of tests.
      > C: Yes. Visa has a test system that maintains known, fake, standard
      > card
      > data. You connect to it the same as the real one and can run
      > transactions against it. I have to find out more about how it
      > works,
      > though it is in that writeup I handed you. So we'll specify some
      > tests
      > using that.
      > P: Let's treat those tests as a separate story, since we don't know
      > what
      > they are now.
      > C: Sounds good.
      > P: OK, I've got enough now to get started. I'll come ask questions as
      > they come up.
      > C: Check. I'll start writing some test data down on paper.
      > P: Good. When you get a few of those, please come interrupt me. I'll
      > want
      > to use them to check my understanding even before we build the
      > tests.
      > For now, I'd estimate that card at 10 days, but we'll know more
      > after
      > we spike the XML Web Service stuff.
      > C: Great. (writes estimate on card)
      > (They kiss. Fade out.)
      >
      > Card: Says almost nothing, perhaps just the name of the story. It's OK
      > to
      > write more on there if you want to. If tempted to write a lot, get
      > smaller
      > cards.
      >
      > Conversation: Covers everything someone cares about, interactively. Both
      > people lead, both follow. Occurs more than once. When P needs more info,
      > he
      > can get it. When C thinks of something, he can talk to P about it.
      >
      > Confirmation: The tests that C and P talked about, and other tests like
      > those that will be refined and filled in.
      >
      > Does that help? If not ... ask more.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Don't be afraid of pair programming:
      > You may not be as good as you think you are, but
      > You're not as bad as you fear.
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 12
      > Date: Tue, 25 Feb 2003 09:09:40 -0500
      > From: Ron Jeffries <ronjeffries@...>
      > Subject: Re: Re: How to write stories for bugs? (and mice ;-)
      >
      > On Tuesday, February 25, 2003, at 8:47:49 AM, jeffgrigg63132
      > <jgrigg@...> wrote:
      >
      >
      >
      > >> Edmund Schweppe wrote:
      >
      > >>> If the Customer is sufficiently technically savvy, they'll
      >
      > >>> know to ask about memory leaks; if not, [...]
      >
      >
      >
      > > Or they'll quite rationally assume that the programmers are
      >
      > > technically savvy enough to know that memory leaks are a bad thing,
      >
      > > and should be avoided.
      >
      >
      >
      > Well, "when you assume ...". If the customer is technically savvy enough
      > to
      >
      > know leaks are bad, they IMO would be derelict in not mentioning it. But
      >
      > see below ...
      >
      >
      >
      > >>> Regardless of the client's level of knowledge, the memory
      >
      > >>> leak is still a defect. For a particular application, the
      >
      > >>> Customer may not care - or may care more about other
      >
      > >>> defects - but it's still a defect.
      >
      >
      >
      > > --- Ron Jeffries <ronjeffries@a...> wrote:
      >
      > >> [...] And I certainly think that memory leaks are a defect and
      >
      > >> usually an important one.
      >
      >
      >
      > > A memory leak is a defect. It's a waste of resources and a violation
      >
      > > of standards. But the priority of fixing it, relative to other
      >
      > > business needs *IS* open to interpretation.
      >
      >
      >
      > Yes. And an iterative development is also open to learning. If no one
      >
      > thinks of memory leaks, and they turn out to be a problem, no process
      > will
      >
      > save the team from a bug. The XP team gets the bug report, uses it to
      >
      > educate the customers and the programmers, and lets the customers decide
      >
      > whether to fix it.
      >
      >
      >
      > > I wrote a small C++ program some years ago that leaked memory quite
      >
      > > profusely. This was intentional: It was a quick and dirty prototype
      >
      > > used to demonstrate that certain kinds of expression parsing could be
      >
      > > done. The production code would be written in PL/I, with no memory
      >
      > > leaks.
      >
      >
      >
      > > For a long running program, typically a service on a server, memory
      >
      > > leaks can be a big problem. For a program that runs and exits, the
      >
      > > most effective way to free memory can be to exit the program,
      >
      > > terminating the process. I'm serious. It's true.
      >
      >
      >
      > Totally agree.
      >
      >
      >
      > > The decision as to when The Customer's time and money should be spent
      >
      > > to improve the efficiency with which the program uses system
      >
      > > resources is The Customer's. Let's allow the customer to make
      >
      > > business decisions regarding their investment.
      >
      >
      >
      > Exactly.
      >
      >
      >
      > Ron Jeffries
      >
      > www.XProgramming.com
      >
      > Talent determines how fast you get good, not how good you get. --
      > Richard Gabriel
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 13
      > Date: Tue, 25 Feb 2003 07:18:21 -0800
      > From: "Van Hamersveld, Mark" <mvanhame@...>
      > Subject: RE: Re: How to write stories for bugs?
      >
      > wecaputo@... wrote:
      > >
      > > Ron:
      > > > please give an example of a defect in the software which should NOT
      > be
      > > > detected by customer tests.
      > > Edmund:
      > > >Memory leak.
      > >
      > > If it can affect the user its going to be
      > > important to them (and they should have an objective measure of its
      > > reality)
      >
      > Wouldn't something like a memory leak belong to the class of "defects"
      > which
      > are automatically taken care of by professional programmers? Wouldn't
      > this
      > be in the same class with producing quality code through refactoring?
      > Even
      > if the user doesn't "see" it or know to ask about it is it not a defect?
      > Sounds like trees falling in the forrest to me.
      >
      > Memory leaks are a smell of bad code and should be taken care of during
      > normal refactoring and not put to the user to create a story for, or an
      > acceptance test for. Certainly the user may have memory usage
      > requirements
      > such as 24/7 operation (which doesn't necessarily pertain to leaking but
      > on
      > efficient use of available memory), small footprint, etc. which should
      > be
      > put into story form with appropriate acceptance tests.
      >
      > Mark
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 14
      > Date: Tue, 25 Feb 2003 09:19:39 -0600
      > From: "Dubbs, Roger" <rdubbs@...>
      > Subject: RE: Velocity & Yesterday's weather
      >
      > Of course I meant "expect", or "challenge". The opposite behaviour
      > would be to just accept the status quo. Somehow I'm quite sure that's
      > not what you're advocating. ;-)
      >
      > Roger
      >
      > > -----Original Message-----
      > > From: Ron Jeffries [mailto:ronjeffries@...]
      > > Sent: Monday, February 24, 2003 5:16 PM
      > > To: extremeprogramming@yahoogroups.com
      > > Subject: Re: [XP] Velocity & Yesterday's weather
      > >
      > >
      > > On Monday, February 24, 2003, at 3:11:47 PM, Dubbs, Roger wrote:
      > >
      > > > Yesterday's Weather is a one-iteration moving average. I
      > > see no harm in using more iterations to smooth the
      > > > expected result somewhat. In fact, the manager is
      > > probably right to demand more tomorrow than he got
      > > > yesterday. That's the road to improvement. When you come
      > > in below the goal, the manager's (and team's!) job
      > > > is to troubleshoot the problem and figure out how to
      > > improve the next iteration.
      > >
      > > > Just my $0.02
      > >
      > > I'm not sure what part "demanding" has in "improvement".
      > >
      > > Ron Jeffries
      > > www.XProgramming.com
      > > Accroche toi a ton reve. --ELO
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > >
      > >
      > >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 15
      > Date: Tue, 25 Feb 2003 10:51:51 -0500
      > From: "Tim Moore" <tmoore@...>
      > Subject: RE: Re: How to write stories for bugs?
      >
      > > -----Original Message-----
      > > From: Ian Collins [mailto:ian@...]
      > > Sent: Monday, February 24, 2003 8:46 PM
      > > To: extremeprogramming@yahoogroups.com
      > > Subject: Re: [XP] Re: How to write stories for bugs?
      > >
      > >
      > > Edmund Schweppe wrote:
      > >
      > > >Ron Jeffries wrote
      > > >
      > > >[ ... ]
      > > >
      > > >
      > > >
      > > >>please give an example of a defect in the software which
      > > should NOT be
      > > >>detected by customer tests.
      > > >>
      > > >>
      > > >
      > > >Memory leak.
      > > >
      > >
      > > That's why I always make sure all tests are run with a
      > > garbage collector
      > > linked in. May not be an option with all languages, but can be a
      > > saviour with C/C++.
      >
      > Garbage collectors aren't a silver bullet, though. They may solve the
      > vast majority of memory management problems in C/C++, but not all of
      > them. You can have objects that are still reachable but never actually
      > used.
      >
      > But, yeah, leak detector programs are readily available...How many
      > people here really use them as a matter of course?
      >
      > --
      > Tim Moore / Blackboard Inc. / Software Engineer
      > 1899 L Street, NW / 5th Floor / Washington, DC 20036
      > Phone 202-463-4860 ext. 258 / Fax 202-463-4863
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 16
      > Date: Tue, 25 Feb 2003 10:57:23 -0500
      > From: "Tom Copeland" <tom@...>
      > Subject: RE: Re: How to write stories for bugs?
      >
      > >
      > > Garbage collectors aren't a silver bullet, though. They may solve the
      > > vast majority of memory management problems in C/C++, but not all of
      > > them. You can have objects that are still reachable but
      > > never actually
      > > used.
      > >
      > > But, yeah, leak detector programs are readily available...How many
      > > people here really use them as a matter of course?
      > >
      >
      > I don't. Most of the stuff I work on currently is in a category someone
      > mentioned earlier - you run it, it does something, and then it exits.
      >
      > I've worked on 24x7 systems that could have used leak detection, but
      > those systems had far more serious problems than a leak detector could
      > identify :-)
      >
      > Yours,
      >
      > tom
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 17
      > Date: Tue, 25 Feb 2003 11:01:58 -0500
      > From: "Tim Moore" <tmoore@...>
      > Subject: RE: Re: How to write stories for bugs?
      >
      > > -----Original Message-----
      > > From: Tom Copeland [mailto:tom@...]
      > > Sent: Tuesday, February 25, 2003 10:57 AM
      > > To: extremeprogramming@yahoogroups.com
      > > Subject: RE: [XP] Re: How to write stories for bugs?
      > >
      > >
      > > >
      > > > Garbage collectors aren't a silver bullet, though. They
      > > may solve the
      > > > vast majority of memory management problems in C/C++, but
      > > not all of
      > > > them. You can have objects that are still reachable but never
      > > > actually used.
      > > >
      > > > But, yeah, leak detector programs are readily available...How many
      > > > people here really use them as a matter of course?
      > > >
      > >
      > > I don't. Most of the stuff I work on currently is in a
      > > category someone mentioned earlier - you run it, it does
      > > something, and then it exits.
      >
      > Fair enough.
      >
      > > I've worked on 24x7 systems that could have used leak
      > > detection, but those systems had far more serious problems
      > > than a leak detector could identify :-)
      >
      > Yeah, that's about where I am now. :-P
      >
      > --
      > Tim Moore / Blackboard Inc. / Software Engineer
      > 1899 L Street, NW / 5th Floor / Washington, DC 20036
      > Phone 202-463-4860 ext. 258 / Fax 202-463-4863
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 18
      > Date: Tue, 25 Feb 2003 16:31:47 -0000
      > From: "David Putman \(DavidPutman.com\)"
      > <davidputman@...>
      > Subject: Re: Re: How to write stories for bugs?
      >
      > > > But, yeah, leak detector programs are readily available...How many
      > > > people here really use them as a matter of course?
      >
      > > I don't. Most of the stuff I work on currently is in a
      > > category someone mentioned earlier - you run it, it does
      > > something, and then it exits.
      >
      > Problem is, if you're selling into a regulated environment, or any
      > environment that tests software before deploying it, they will detect
      > your
      > memory leaks for you.
      > If you're happy for them to do that, fine but it can be an unnecessarily
      > painful lesson to learn.
      > Let's not make the mistake of thinking that we're the only people who
      > know
      > about these things.
      >
      > Dave P
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 19
      > Date: Tue, 25 Feb 2003 11:38:25 -0500
      > From: Edmund Schweppe <schweppe@...>
      > Subject: Re: Re: How to write stories for bugs?
      >
      > Ron Jeffries wrote:
      > > On Monday, February 24, 2003, at 10:37:15 PM, Edmund Schweppe wrote:
      >
      > [re: memory leaks]
      >
      > > > Is it still a defect if the Customer doesn't think it's important
      > enough
      > > > to have a test and get it fixed? I think so - an unimportant defect,
      > but
      > > > a defect none the less. Of course, other folks' mileage may vary.
      > > Sure. And still it needs to go through the customer, because (in XP)
      > only
      > > the customer can decide.
      >
      > I agree wholly that, once the defect has been recognized and the cost of
      > fixing has been estimated, only the XP Customer can decide whether or
      > not it's worth fixing. My point (for what it's worth) is that the memory
      > leak is a defect in all these cases:
      > a) when nobody knows about it;
      > b) when its effects are noticed but before it's actually found;
      > c) when it's been found but before it's been fixed.
      >
      > As several other posters have noted, lots of memory leaks never have
      > enough effect to be noticed. Others may be noticed but left unfixed for
      > a variety of reasons - in the XP case, specifically including the
      > situation where the Customer says not to bother. Stil others get fixed.
      >
      > In all cases, the leaks are defects; only in the latter cases do XP
      > Customers make any decisions about them, and only in the last case would
      > an XP Customer specify a Customer Test that checks for the leak's
      > absence. Or so it seems to me.
      >
      > --
      > Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
      > The opinions expressed herein are at best coincidentally related to
      > those of any past, present or future employer.
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 20
      > Date: Tue, 25 Feb 2003 08:45:58 -0800
      > From: "Van Hamersveld, Mark" <mvanhame@...>
      > Subject: RE: Re: How to write stories for bugs?
      >
      > It is my understanding from these posts that a story can be completed
      > and
      > called "done", even if it has defects that the programmers know exist,
      > but
      > the customer hasn't found. Is that a true statement?
      >
      > If so, the programmers are *knowingly* releasing buggy code. What is
      > stopping programmers then from racing through stories to get them "done"
      > and
      > making their personal velocity appear high, when infact, their sloppy
      > work
      > creates many additional stories that impact the entire project
      > negatively?
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 21
      > Date: Tue, 25 Feb 2003 10:59:52 -0600
      > From: Brad Appleton <brad@...>
      > Subject: Re: Re: How to write stories for bugs?
      >
      > You guys do realize you're talking about the classic function of change
      > control boards (CCBs) - yes? I realize CCB is a term eschewed by many
      > agilists as it's all too often associated with big projects and big
      > process. But at it's heart, its simply about how one goes about
      > explicitly making shared decisions about what requests get implemented
      > and when (regardless of whether its a bug/feature or whatnot).
      >
      > Thus anything "new" that impacts any of the "four variables" (cost,
      > quality, schedule, scope) is a potential project issue/risk and must be
      > analyzed, estimated, and prioritized. If the XP way for managing this is
      > using StoryCards, then I would surmise that any new issue impacting any
      > of those 4 variables in a way that is "customer visible"gets its own
      > story.
      >
      > If so, it seems that in XP, the "Story" is not merely a unit of testable
      > "business value" to be delivered, but also anything that needs to be
      > estimated and prioritized.
      >
      > --
      > Brad Appleton <brad@...> www.bradapp.net
      > Software CM Patterns (www.scmpatterns.com)
      > Effective Teamwork, Practical Integration
      > "And miles to go before I sleep." -- Robert Frost
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 22
      > Date: Tue, 25 Feb 2003 17:03:52 -0000
      > From: "Kiel Hodges <kielhodges@...>"
      > <kielhodges@...>
      > Subject: Re: Velocity & Yesterday's weather
      >
      > --- In extremeprogramming@yahoogroups.com, "Ryan Ripley"
      > <ripley@i...> wrote:
      >
      > > Isnt change constant though? I think its dangerous to rely
      > soley on
      > > *Yesterday's Weather*. In otherwords, can we truely/honestly
      > ever make the
      > > assumption that "team and enviroment are staying relatively
      > constant"?
      >
      > Dangerous? It shouldn't be. You're just making plans. Things
      > never go exactly as planned. Don't set things up so that
      > someone's life or the health of the company depends on your
      > predicted velocity being exactly right (no matter how you make
      > your prediction.)
      >
      > In general, we cannot make the assumption that things stay
      > completely constant. Nor can we assume that the next iteration's
      > velocity will be the exactly the same as the average of all
      > previous velocities. We're only getting a rough prediction. I
      > prefer using the straightforward rough prediction of yesterday's
      > weather instead of calculating averages to get a prediction
      > essentially as rough.
      >
      > > I'm wondering what the rule says about developer X having a new
      > child at
      > > home, or developer Y having a serious conflict with developer Z
      > over some
      > > crazy, yet common, corporate issue. While yes these issues
      > typically have
      > > nothing to do with *software development*, I think that they do
      > *seriously*
      > > impact project velocities.
      >
      > If the rule says I should ignore these factors, then I would
      > invoke the "They're Just Rules" rule. In practice, my teams
      > predicted future velocity through discussions. We used
      > Yesterday's Weather as a starting point (because it's simpler)
      > and raised whatever issues we thought might impact the velocity.
      > For example, after a couple of iterations that targetted and hit
      > 120 points, we all felt that we hit the numbers through luck and
      > a pace that was not sustainble. After a brief discussion, we
      > agreed to 100 points as our velocity for the next iteration.
      >
      > I think using averages or running averages might just discourage
      > these kinds of discussions. I believe these discussions are much
      > more valuable in predicting velocity. They also improve the
      > overall effort in other ways. For example, it might come out that
      > the team squeaked by because those acceptance tests that were
      > available only late in the iteration passed the very first time.
      > Now the team has an opportunity to improve the process.
      >
      > Kiel Hodges
      > SelfSo Software
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 23
      > Date: Tue, 25 Feb 2003 09:13:16 -0800
      > From: "Dan Rawsthorne" <DrDan@...>
      > Subject: RE: Writing User Stories
      >
      > Use Cases and User Stories have different goals:
      > * the Use Case is for communicating to users - telling them what
      > they'll be getting from the system. They are based on the Goal being
      > produced. Because they exist to support the User's understanding, their
      > format and size must be based on the needs of the User validating them.
      > * User Stories are a bite-sized bit of functionality that can be
      > delivered in a relatively short time. Because they are used to control
      > development, their format and size is based on the needs of the
      > Developer and Customer - they must be able to be sized, prioritized, and
      > developed
      >
      > The Customer Team has the unenviable job of converting Use Cases (if
      > your project uses them) to the User Stories needed to drive development.
      > I use a technique called the Ever-Unfolding Story for this, and the
      > ratio seems to be about 10-50 User Stories per Use Case.
      >
      > Let me take a simplistic view in order to explain further. A Use Case
      > consists of *all* scenarios an Actor might use to accomplish the same
      > goal. A typical use case may have dozens of scenarios, including all the
      > alternative and failure ones. Each of these scenarios is a candidate for
      > a User Story - each provides a chunk of functionality that is of benefit
      > to the Actor, and they are often small enough to be estimatable...
      > additional decomposition and recomposition is necessary to get them to
      > final size, but you get the idea...
      >
      > Dan ;-)
      >
      > Dan Rawsthorne, PhD, Sr. Consultant
      > www.netobjectives.com
      > DrDan@...
      > office: 425-531-0814
      >
      > Net Objectives' vision is effective software development without
      > suffering. Our mission is to assist software development teams in
      > accomplishing this through a combination of training and mentoring.
      >
      >
      > > -----Original Message-----
      > > From: Nicholas Robinson [mailto:nicholasrobinson@...]
      > > Sent: Tuesday, February 25, 2003 12:14 AM
      > > To: extremeprogramming@yahoogroups.com
      > > Subject: Re: [XP] Writing User Stories
      > >
      > > Hi Jeff,
      > >
      > > Thanks for that. When we think of use cases, we sit down and consider
      > > what the goals of the user
      > > is. He wants to make a payment, make an order, track an order. Is
      > this
      > > the same granularity as
      > > the user story, but in a less formal format? Is a story broken down
      > into
      > > task cards? I need to
      > > re-read some of the Kent Beck stuff, but any practical guidance is
      > most
      > > appreciated.
      > >
      > > Regards
      > >
      > > Nick.
      > > --- Jeff Nielsen <jeff.nielsen@...> wrote: > From the
      > green
      > > book (Planning XP):
      > > >
      > > > "A user story is a chunk of functionality that is of value to the
      > > customer."
      > > >
      > > > It provides a simple way for developers and customers to partition
      > what
      > > the
      > > > system needs to do so that it can be delivered in pieces.
      > > > A story must be:
      > > >
      > > > 1.1. Understandable to customer/developer
      > > > 2.2. Testable
      > > > 3. 3.Valuable to the customer
      > > > 4. Small enough to build a few each iteration
      > > > -
      > > >
      > > > These four criteria have helped me keep people on track who are new
      > to
      > > > deciding "what is a story".
      > > >
      > > > Jeff Nielsen
      > > > Digital Focus (www.digitalfocus.com)
      > > >
      > > > ----- Original Message -----
      > > > From: <nicholasrobinson@...>
      > > > To: <extremeprogramming@yahoogroups.com>
      > > > Sent: Monday, February 24, 2003 10:58 AM
      > > > Subject: [XP] Writing User Stories
      > > >
      > > >
      > > > > Hi,
      > > > >
      > > > > I have two books on XP, and both dont seem to explain fully what a
      > > > > User Story is. Can someone either explain to me, as if I know
      > only
      > > > > of Use Cases, or maybe point me to a link? I need to swot up on
      > them
      > > > > because on Wednesday the XP Workshop I am in is gonig to start
      > > > > producing the requirements for the two projects we have decided to
      > > > > build applying XP. Nobody as yet, knows 100% how to write User
      > > > > Stories or how to plan, so any pointers to any good online
      > resources
      > > > > would be most welcome.
      > > > >
      > > > > Thanks,
      > > > >
      > > > > Nick.
      > > > >
      > > > >
      > > > >
      > > > > To Post a message, send it to: extremeprogramming@...
      > > > >
      > > > > To Unsubscribe, send a blank message to:
      > > > extremeprogramming-unsubscribe@...
      > > > >
      > > > > ad-free courtesy of objectmentor.com
      > > > >
      > > > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > > > >
      > > > >
      > > >
      > > >
      > > > To Post a message, send it to: extremeprogramming@...
      > > >
      > > > To Unsubscribe, send a blank message to: extremeprogramming-
      > > unsubscribe@...
      > > >
      > > > ad-free courtesy of objectmentor.com
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > >
      > > __________________________________________________
      > > Do You Yahoo!?
      > > Everything you'll ever need on one web page
      > > from News and Sport to Email and Music Charts
      > > http://uk.my.yahoo.com
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to: extremeprogramming-
      > > unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.com
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > >
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 24
      > Date: Tue, 25 Feb 2003 17:13:34 -0000
      > From: "Kiel Hodges <kielhodges@...>"
      > <kielhodges@...>
      > Subject: Re: How to write stories for bugs?
      >
      > --- In extremeprogramming@yahoogroups.com, "Van Hamersveld, Mark"
      > <mvanhame@a...> wrote:
      > > It is my understanding from these posts that a story can be
      > completed and
      > > called "done", even if it has defects that the programmers know
      > exist, but
      > > the customer hasn't found. Is that a true statement?
      >
      > Not in my opinion. If a developer "finishes" a story and has all
      > of the acceptance tests working, then realizes that there could
      > be memory leaks or other defects, she should either just fix them
      > (if they are very small) or discuss them with the customer.
      >
      > > If so, the programmers are *knowingly* releasing buggy code.
      > What is
      > > stopping programmers then from racing through stories to get
      > them "done" and
      > > making their personal velocity appear high, when infact, their
      > sloppy work
      > > creates many additional stories that impact the entire project
      > negatively?
      >
      > Honesty? Integrity? The ability to look ahead? Pair partners?
      > After it happens the first time, the coach and every honest team
      > member with integrity? After the second time, the absence of the
      > offender from the team?
      >
      > Kiel Hodges
      > SelfSoSoftware
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      > Message: 25
      > Date: Tue, 25 Feb 2003 12:26:38 -0600
      > From: wecaputo@...
      > Subject: RE: Re: How to write stories for bugs?
      >
      >
      > Mark:
      > >Wouldn't something like a memory leak belong to the class of "defects"
      > which
      > >are automatically taken care of by professional programmers?
      >
      > Preventing memory leaks, yes. If say we are using C++, writing classes
      > that
      > clean up after themselves properly and intelligent use of smart pointers
      > are good design decisions. OTOH, as others have pointed out, this could
      > be
      > overdesign for a short running utility. (VB references can "leak" too,
      > same
      > deal)
      >
      > Discovered memory leaks are a different animal. This thread is (was?)
      > about
      > stories for bugs. A defect by definition is a code "feature" that has
      > made
      > it out of the programmer's control and into the customer's. So the
      > customer
      > needs a test -- either proactively to prevent the defect getting into
      > production, or reactively after a user notices the problem.
      >
      > >Wouldn't this
      > >be in the same class with producing quality code through refactoring?
      > Even
      > >if the user doesn't "see" it or know to ask about it is it not a
      > defect?
      > >Sounds like trees falling in the forrest to me.
      >
      > No, I don't think anyone is recommending a "let's see what we can sneak
      > past the customer" strategy. I personally put honesty and integrity
      > ahead
      > of the XP values, and I wouldn't tolerate such deception on a team I
      > worked
      > on. I think we are talking about leaks that the programmer's just miss.
      > Even with full honesty and professionalism, mistakes are made. Switch it
      > around, you are the customer, are you going to leave it to the
      > programmer's
      > infallibility to find and fix bugs, or are you going to want tests?
      >
      > >Memory leaks are a smell of bad code and should be taken care of during
      > >normal refactoring and not put to the user to create a story for, or an
      > >acceptance test for.
      >
      > Again, s*** happens. We can wait until it does, or try to catch it
      > before
      > it does in multiple nets. (I am a multiple net kinda guy)
      >
      > >Certainly the user may have memory usage requirements
      > >such as 24/7 operation (which doesn't necessarily pertain to leaking
      > but
      > on
      > >efficient use of available memory), small footprint, etc. which should
      > be
      > >put into story form with appropriate acceptance tests.
      >
      > I think (once again) we are in violent agreement. ;-)
      >
      > Best,
      > Bill
      >
      > William E. Caputo
      > ThoughtWorks, Inc.
      > --------
      > It is impossible to design a system so perfect that no one needs to be
      > good. -- T.S. Eliot
      >
      >
      >
      >
      >
      >
      > ________________________________________________________________________
      > ________________________________________________________________________
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.