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

155729Re: [XP] INVEST stories and estimations

Expand Messages
  • Stephan Huez
    Sep 30, 2010
    • 0 Attachment
      Hi Steve,

      You're right. I reckon that not re-estimating the story won't be a
      disaster. I don't think I would do it, actually. Too much time spent
      on estimates is definitely a waste of time and velocity is the great
      equaliser.

      By the way, I am well aware of the philosophy behind agile estimates
      and I fully embrace it. My only problem is that I work in a company
      that builds software for other companies, on fixed-price contracts.
      Hence a different kind of pressure on estimates. Nevertheless, even
      though I strive to work in a fully agile fashion, mentalities take
      time to change :-)

      Kind regards,

      Stephan

      On 30 September 2010 08:42, Steven Gordon <sgordonphd@...> wrote:
      > 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]
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to:   extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.comYahoo! Groups Links
      >
      >
      >
      >



      --
      Stephan Huez
      Blog: http://softwareinabottle.wordpress.com/
    • Show all 14 messages in this topic