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

155726Re: [XP] INVEST stories and estimations

Expand Messages
  • Stephan Huez
    Sep 29 11:13 PM
      Hi Chet,

      Thanks very much for the explanation.

      > Now comes the tricky bit. Do we really need a database to do the
      > first story?

      I fully agree. Even when it is obvious that a database will be needed in the
      end, one can always defer it until it becomes an absolute necessity. I see
      that it can even be helpful to avoid wasting time making changes in the
      database tables while discovering the domain.

      > If we believe that our initial premise is correct, that each story must be
      > independent and pay for only their fair share of infrastructure, then
      > the answer must be no.

      > We must find some low cost way of holding onto the data, one that
      > meets the story's requirements, but does not cause us to buy, install,
      > and configure Oracle.

      When the need for a database eventually arises, what is your approach to
      take it into account? Do you add it as acceptance criteria for a new
      feature? Or do you rather create a story like "make xxx persistent"? I guess
      it would be the first one as it adds functionality to the system while the
      second does not.

      > Since our code is well factored and modular, there will be a place,
      > and only one place, where we retrieve the stored data. In coding our
      > first story, we will find a simple solution: one appropriate to a
      > system that only retrieves a few names and does nothing else, and that
      > is what we will call from our one place. As our program grows, that
      solution
      > will no longer be appropriate, and we will go to our one place and
      > change it. One day we may find that we actually need Oracle, and when
      > we do, we will go to our one place and call it.

      Thanks to simple design, YAGNI and continuous refactoring, the system is
      always in a state that allows adding new functionality in a fast and clean
      fashion. However, a story that would be the first to hit the database would
      need more work. The story should be re-estimated because the assumptions
      changed, shouldn't it?

      If I try and summarise: We can start off by simply estimating all the
      stories without even paying attention to the database need. When we no
      longer have the choice and really need to use a database, we can then
      re-estimate one or more stories that would be affected by this new piece of
      information. Is this scenario correct?

      Kind regards,

      Stephan

      On 29 September 2010 16:52, Chet Hendrickson <lists@...>wrote:

      >
      >
      > Hello Stephan,
      >
      > Your confusion on this is not uncommon, and quite understandable.
      > First off, we really do mean that stories should be independent. They
      > should have no technical dependences. Each should pay only its fair
      > share of infrastructual overhead.
      >
      > Making our stories independent at the technical level requires us to
      > make some changes in how we think about our architectures and
      > infrastructures.
      >
      > Imagine the first story we pick up asks to retrieve a bit of data,
      > let's say someone's name. Some may say that you could not do that
      > story first, because we haven't done the story that saves the name.
      > In truth that story may not be very interesting with out the name entry
      > story, but it can obviously be done, you can even test it.
      >
      > Now comes the tricky bit. Do we really need a database to do the
      > first story?
      >
      > If we believe that our initial premise is correct, that each story must be
      > independent and pay for only their fair share of infrastructure, then
      > the answer must be no.
      >
      > We must find some low cost way of holding onto the data, one that
      > meets the story's requirements, but does not cause us to buy, install,
      > and configure Oracle.
      >
      > Since our code is well factored and modular, there will be a place,
      > and only one place, where we retrieve the stored data. In coding our
      > first story, we will find a simple solution: one appropriate to a
      > system that only retrieves a few names and does nothing else, and that
      > is what we will call from our one place. As our program grows, that
      > solution
      > will no longer be appropriate, and we will go to our one place and
      > change it. One day we may find that we actually need Oracle, and when
      > we do, we will go to our one place and call it.
      >
      > chet
      >
      >
      > Wednesday, September 29, 2010, 8:54:33 AM, you wrote:
      >
      > >
      > > Hi all,
      >
      > > I guess this point must have already been asked but I couldn't find it
      > > in the history of messages. I'd be happy to be pointed to any existing
      > > answer :) I also googled on the topic and haven't found any
      > > satisfying answer for the whole issue so far.
      >
      > > So, here is the point I'm having trouble with:
      >
      > > When writing stories with a team, I always try to come up with stories
      > > that follow the INVEST guideline. However independent I try to make
      > > them, in the end, there is always a discussion relating to the
      > > database.
      >
      > > I follow the idea that stories shall be vertical slices of the
      > > product. Therefore, many stories will eventually hit the database.
      > > When there are several stories that deal with the same concept, they
      > > will deal with the same database tables. Even though the stories are
      > > independent from a business perspective, broken down as CRUD
      > > operations for example, developers see them as technically dependent
      > > because they all deal with the same tables. Actually, they deal with
      > > the same domain objects, etc.
      >
      > > I have to issues here:
      >
      > > 1/ Independence
      > > Am I wrong by understanding that the "I" in INVEST has to do with
      > > business independent and not technical layer independent? There is no
      > > absolute independence either.
      >
      > > In order to achieve such independence, I try not to split stories too
      > > early so that they remain as independent as possible as long as
      > > possible. When stories reach the top of the stack, they can be broken
      > > down again. I think that some dependencies at that moment are
      > > acceptable, not to say unavoidable.
      >
      > > How do you deal with such stories? What would you recommend ?
      >
      > > 2/ Estimates
      > > If I have CRUD operations for instance, the question that come from
      > > the teams are always: how do you estimate those stories because they
      > > are "technically" dependent. The next question is then: how do we
      > > estimate the common part. Indeed, the first story that will be
      > > implemented will have to create the database table and the domain
      > > objects and so on and so forth.
      >
      > > I see different approaches:
      > > A/ Shall we estimate each story so that individual estimates each
      > > considers the initial effort?
      > > B/ Or shall we distribute initial effort over the stories?
      > > C/ Or shall we put the effort on one story and consider in the others
      > > that the foundations are present?
      > > D/ Or shall we just consider that the estimates will average out in
      > > the end so that the envisaged "overhead" does not really matter?
      >
      > > I would be more inclined towards the last option. However, in the
      > > article of William Wake, INVEST in Good Stories and SMART Tasks, he
      > > writes:
      >
      > > << We can't always achieve this; once in a while we may say things
      > > like "3 points for the first report, then 1 point for each of the
      > others.">>>
      >
      > > This is typically the C/ approach.
      >
      > > I am very much interested to know you usually address this topic.
      >
      > > Thanks very much in advance,
      > > --
      > > Stephan Huez
      > > http://softwareinabottle.wordpress.com/
      > >
      >
      > --
      > Best regards,
      > Chet Hendrickson mailto:lists@...<lists%40hendricksonxp.com>
      > Check out our upcoming CSM Plus courses @
      > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
      >
      >
      >



      --
      Stephan Huez
      Blog: http://softwareinabottle.wordpress.com/


      [Non-text portions of this message have been removed]
    • Show all 14 messages in this topic