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

155727Re: [XP] INVEST stories and estimations

Expand Messages
  • Steven Gordon
    Sep 29, 2010
      On Wed, Sep 29, 2010 at 11:13 PM, Stephan Huez <stephan.huez@...>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.
      >
      >
      > > 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?
      >
      >
      What horrible thing would happen if you did not re-estimate the story where
      the database becomes necessary?

      The objective is to deliver working software. It takes just as much time to
      do the work whether the estimates are accurate or not. If it takes the team
      N person-hours to reestimate a story, that would be N person-hours not
      developing working software.

      The point of agile estimation is to get consistent ballpark estimates as
      quickly as possible, so there is more time to do real work. Just, do quick
      consistent estimates and let velocity calibrate out any errors over time.

      That is why it does not really matter whether you build the database
      development overhead into the first slice, average it out among the slices
      or even ignore it. The same error will appear in all the stories, so it
      will affect your velocity fairly evenly over time.

      SteveG


      > 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
      > >
      > >
      > >
      >
      > --
      > Stephan Huez
      > Blog: http://softwareinabottle.wordpress.com/
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >


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