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

Re: [scrumdevelopment] Story Cards for Building A Data Store

Expand Messages
  • Mike Cohn
    If we took things to an extreme, we might want to not even assume software is involved. That might be OK at the very, very, very beginning of a project but I
    Message 1 of 4 , Sep 20, 2006
    • 0 Attachment
      If we took things to an extreme, we might want to not even assume software is involved. That might be OK at the very, very, very beginning of a project but I took as an assumption the subject line in the email ("building a data store"). We might start an analysis bit of activity by thinking about what data sources we need, then we'd move down into the stories I suggested. Note, though, that at first with those I didn't assume there'd be a transform. I started with stories that were loading from the source into the data store. Then as the story was discussed further we discovered transform steps are needed.

      Still, I don't think there's any value about artificially distancing ourselves from obvious assumptions. A classic example is that in the design of an ATM we shouldn't assume there's a numeric keypad through which I enter a PIN. Rather there's just a way I authenticate myself to the ATM. Perhaps that's a finger scan. So, it would be best to write an ATM story without the assumption of exactly how I authenticate. It would be pointless, though, to pretend we didn't know whether the ATM was going to dispense bills rather than gold ingots.

      Regards,
      Mike Cohn
      Author:
        Agile Estimating and Planning
        User Stories Applied
      www.mountaingoatsoftware.com


      On Sep 20, 2006, at 2:04 AM, PaulOldfield1@... wrote:

      (responding to Mike)
       
      > Sometimes the transformation may be very time consuming
      > in which case I'd call that out in its own story.
       
      I find it a bit worrying that several of the stories here have an
      assumption that there will be some sort of "Extract, Transform,
      Load" solution.  I'm not too keen on getting that close to
      solutions in requirements.
       
      What guidelines do you have in this respect?  Is it reasonable
      to say this is a pragmatic way of writing the requirements
      because we already know an ETL solution will be used?
       
      Paul Oldfield
       

    Your message has been successfully submitted and would be delivered to recipients shortly.