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

Re: [scrumdevelopment] Re:Requirements documents and Scrum

Expand Messages
  • mpkirby
    We use documentation as a way to convey intent across distance and time. So during the development, we generally use stories and test cases. But when we are
    Message 1 of 9 , Jan 25, 2008
    • 0 Attachment
      We use documentation as a way to convey intent across distance and time.

      So during the development, we generally use stories and test cases. But
      when we are done, our product may live 20 years. So 10 years from now
      when a new feature is added to this area, how do you figure out what is
      going on?

      Dig out the index cards? Not likely. Review the unit tests? Reading
      code is too hard.

      How about the customer acceptance tests? (turns out they are very
      voluminous).

      It happens that a 3 or 4 page "specification" of "tagged requirements"
      organized by "function/feature" is an easy way to understand the
      incremental or changed content of part of the program.

      It's not "overly detailed" nor is it "general to the point of
      uselessness". I'm sure the level of detail would vary based on
      organization and circumstance. But it works for us.

      In general we want an observer looking backwards on our development to
      not be able to tell whether or not we developed the code first, or the
      requirements. (mostly it is the requirements, but often it is not).

      Mike




      > Roy Morien wrote:
      >>
      >> OK, so documentation and the need for it or not is again a vexing
      >> question.
      >>
      >> So tell me, please, exactly what is supposed to be in a 'requirements
      >> document'? At one end of the scale it might be a simple statement
      >> such as 'we need a payroll system including an HR department
      >> website'. Or it might be inches thick and gives details down to which
      >> font to use and what the colour scheme is.
      >>
      >> I have often written down my thinking in a document, just to clarify
      >> things. And often these thoughts have been included in a system
      >> manual later on. But the fact is, creating a fully detailed,
      >> comprehensive, all inclusive document is at least a 50% waste of time.
      >>
      >> So ... what goes in the perfect requirements document?
      >>
      >> Also, I think the statement of standards in an organisation should
      >> state many of the details that are often put into a requirements
      >> document. Do you have a statement of standards?
      >>
      >> Too often the creation of a large document is just a proxy for making
      >> progress. It is a substantial piece of work, and can always be
      >> flaunted as proof that we are really doing something ... Look how big
      >> it is!!!
      >>
      >> Any document must be carefully scrutinised for its true purpose, its
      >> correct content, for its intended audience, for its subsequent
      >> maintainability, for its success at communication correct and useful
      >> information to its intended audience etc.
      >>
    Your message has been successfully submitted and would be delivered to recipients shortly.