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

Re: [XP] INVEST stories and estimations

Expand Messages
  • Stephan Huez
    Hi Steven, Thanks for the feedback. What we try to do is to use both classic estimation for the bid but also try and see with what result we come with agile
    Message 1 of 14 , Oct 1, 2010
    • 0 Attachment
      Hi Steven,

      Thanks for the feedback.

      What we try to do is to use both classic estimation for the bid but also try
      and see with what result we come with agile estimation. We can then compare
      both techniques and learn. Up until now, the classic estimates are used for
      the pricing. When we start off the project, we re-estimate completely in an
      agile fashion and work with those estimates from then on.

      I hope that some day, I will work for a customer on a win-win partnership
      :-)

      Kind regards,

      Stephan

      On 30 September 2010 15:19, Steven Gordon <sgordonphd@...> wrote:

      >
      >
      > On Thu, Sep 30, 2010 at 1:23 AM, Stephan Huez <stephan.huez@...<stephan.huez%40gmail.com>
      > >wrote:
      >
      >
      > >
      > >
      > > 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.
      > >
      >
      > Yes, fixed price makes agile a challenge.
      >
      > Agile estimation is for steering the project. It is not a good fit for
      > bidding a project. If the client cannot be convinced to move to a different
      > kind of arrangement (fixed price is wasteful, making software development
      > more expensive for the client; it also creates an adversarial relationship
      > instead of a win-win partnership), then it may be best to do a detailed
      > non-agile estimation to determine the bid, but then throw out all those
      > up-front assumptions when actually doing the work.
      >
      >
      > > 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
      > >
      > >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >



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


      [Non-text portions of this message have been removed]
    • 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 2 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.