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

Re: [XP] INVEST stories and estimations

Expand Messages
  • Stephan Huez
    Hi Chet, Thanks for the feedback. On the other hand, I almost always see customers requiring a database because they already have an infrastructure.
    Message 1 of 14 , Oct 1, 2010
    • 0 Attachment
      Hi Chet,

      Thanks for the feedback.

      On the other hand, I almost always see customers requiring a database
      because they already have an infrastructure. Nevertheless, I find it very
      beneficial to defer the usage of a database as late as possible because of
      the overhead it can sometimes create while discovering the domain.

      Kind regards,

      Stephan

      On 30 September 2010 15:29, Chet Hendrickson <lists@...>wrote:

      >
      >
      > Hello Stephan,
      >
      >
      > Thursday, September 30, 2010, 2:13:54 AM, you wrote:
      >
      > >
      > > 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.
      >
      > The need for the database should arise from the stories the Customer
      > is naturally bringing to the team. If it doesn't, well then...
      >
      >
      > >> 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?
      >
      > I am afraid that that is often the case.
      >
      >
      > > 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?
      >
      > Exactly.
      >
      > chet
      >
      >
      > > Kind regards,
      >
      > > Stephan
      >
      > > On 29 September 2010 16:52, Chet Hendrickson <lists@...<lists%40hendricksonxp.com>
      > >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>
      > <lists%40hendricksonxp.com>
      >
      > >> Check out our upcoming CSM Plus courses @
      > >> http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
      > >>
      > >>
      > >>
      >
      > --
      > 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]
    Your message has been successfully submitted and would be delivered to recipients shortly.