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

Re: BRUF

Expand Messages
  • Anthony Williams
    ... Maybe. ... I woudl prefer to not do BRUF, but there may be situations where it is required (e.g. for tendering a bid, as described by Ken). I don t feel
    Message 1 of 59 , Sep 1, 2004
    • 0 Attachment
      "Jason Nocks" <nocksj@...> writes:

      >> "Jason Nocks" <nocksj@...> writes:
      >>
      >>> Clearly, we need to combat "requirements creep". Also clear to me is
      >>> that
      >>> requirements requested up-front are often far off the mark, so there
      >>> should be some effort towards minimizing wasted effort.
      >>
      >> Unless I misunderstand the term "requirements creep", I fail to see why it
      >> is
      >> an issue on an Agile project. The initial requirements may bear very
      >
      > I actually completely agree with this. I think it shouldn't be a problem
      > as well. I think it's quite possible that we have different definitions of
      > "requirements creep", and unfortunately, I think humans will cause it to
      > be reality that must be dealt with.

      Maybe.

      > I also don't believe that an XP team should be doing BRUF at all. Do you
      > feel differently. I can't tell from your post. The context in this case
      > was adding BRUF to XP (I think), and I believe that BRUF is a holdover
      > from Waterfall. Do you think BRUF should be an Agile practice? I can't
      > tell from your post.

      I woudl prefer to not do BRUF, but there may be situations where it is
      required (e.g. for tendering a bid, as described by Ken).

      I don't feel that BRUF would necessarily impact the rest of the project.

      >> little
      >> relation to the final delivered software, but this is not an issue
      >> provided
      >> software is delivered frequently, and each iteration the most important
      >> current requirements are delivered. If requirement creep, morph, get cut
      >> or
      >> otherwise change, this is not an issue; you just address the changed
      >> requirements in the next iteration. If there's still more requirements,
      >> and
      >> there's still budget available, then you just schedule another iteration.
      >
      > I think it's possible that we have vastly different notions of
      > "requirements creep". I most likely did not clearly communicate my
      > understanding of the term. To me, the term closely resembles a term I've
      > heard before, called "scope creep". To me, that term indicates features
      > that are implemented but that are outside the scope of what's trying to be
      > solved.

      That's the analogy I was thinking of too --- the tendency to add more and more
      requirements, to "ensure we haven't missed anything".

      > IMO, in BRUF, this cruft gets sucked in like a vacuum cleaner. I think it
      > happens when the requirements gatherers start saying things like "Let's
      > list everything we might possibly need". Sound familiar? I think the data
      > point (64% of Waterfall-Requested features used "rarely" or worse)
      > supports this notion.

      I agree that you may end up with a large list of initial requirements, but I
      don't think that is a particular issue, provided the customer can prioritize
      them. Of course, any time spent thinking about them is wasted, but if you have
      to do BRUF, then it's a cost you have to handle.

      > I agree that XP planning games fight this trend much more effectively than
      > anything else I've encountered. But, a team really following XP (including
      > the Customer) wouldn't do BRUF IMO. If the team, or even just one member
      > of the team (the Customer) wants to do BRUF, then I think that impacts the
      > XP Planning Game somewhat. I'm not sure how, but I have some concerns
      > based on the above data point and past experience.

      If you have done BRUF, it might make the planning game take longer (it must
      take longer to prioritize 3000 requirements versus 30) However, I think this
      is a one-time cost; once requirements have been pushed down the list, then
      there's no reason to ever think about them until we get that far down the list
      unless someone actively chases for them.

      > I don't want to assume that an XP team is completely immune from
      > "requirements creep" (whatever that means). If one member of the team
      > becomes infected (the Customer) with "we might need this" and "we might
      > need that" kind of pressures from others and allows those pressures to
      > influence the priorities of stories, I think we have a problem. I could
      > certainly be wrong.

      If the customer bows to "we *might* need this" over "we *do* need that", then
      you're lost, I agree. I don't think it matters whether you've thought of
      "this" and "that" up front, or whether they are new requirements that come
      along as the project progresses.

      > It's very easy to just say "that's the customer's problem", but I don't
      > believe in blaming members of the team for being human.

      It's up to the Whole Team to help them not bow to these pressures.

      > How do we know that we haven't implemented a single feature that is not
      > truly needed? How do we know that we are completely immune from this
      > problem? Certainly if you develop a close relationship with the Customer
      > and work closely (onsite), this descreases the likelihood. But, are we
      > collecting data that proves that every feature implemented is used often
      > or higher? Or, is that too high of a mark to strive for?

      We don't know in advance that any feature we implement will be used. However,
      if we address the highest priorities first, and release often, and get real
      feedback on the releases, then we stand a high chance of being reasonably on
      target.

      Anthony
      --
      Anthony Williams
      Senior Software Engineer, Beran Instruments Ltd.
    • Dominic Williams
      ... Not if the people say that XP was the main cause of their motivation. Regards, Dominic Williams http://www.dominicwilliams.net
      Message 59 of 59 , Sep 8, 2004
      • 0 Attachment
        Ken Boucher wrote:

        > Do you mean Mike, that if I want to dismiss the
        > success of an agile software project, instead of
        > saying that they were just lucky, I can just say they
        > were motivated and that's how the people found a way
        > to get it done?

        Not if the people say that XP was the main cause of
        their motivation.

        Regards,

        Dominic Williams
        http://www.dominicwilliams.net

        ----
      Your message has been successfully submitted and would be delivered to recipients shortly.