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

Re: [scrumdevelopment] Best approach to "Agile Documentation"

Expand Messages
  • Jeff Anderson
    Saying to write just what the product owner and developers wants seems a little bit like hand waiving. I m rarely in a situation where we have just one
    Message 1 of 51 , Feb 1, 2010
    • 0 Attachment
      Saying to write "just what the product owner and developers wants"
      seems a little bit like hand waiving.

      I'm rarely in a situation where we have just one product owner, and
      even when we do the product owner needs advice on what to document.

      If you are in a sensitive field, you or your product owner may have
      risk officers or security experts to consult, if you have a separate
      support group someone better consult them on what they need to keep
      this running.Its not just about developers and product owners. Sure
      don't document to follow a process, but that doesn't mean you can't
      offer some advice on some docs that help in certain situations.

      I tend to use (in the following order)
      -tests (automated and manual)
      -support and operation guides
      -func hirerarchy (like epics and stories)
      -platform and arch outline
      -domain driven design style models (ie concise and compact)

      I like scott amblers agile documentation, a colleague of mine gives an
      overview at...

      http://agileconsulting.blogspot.com/2009/12/agile-documentation.html

      Regards
      Jeff Anderson

      On 1/26/10, James Schiel <schiel@...> wrote:
      > Ron, I was thinking about a different way to say this, but I think you've
      > really captured it.
      >
      > However, let's provide a few examples that Joshua might need to be aware
      > of----
      >
      > 1) What documentation does the Product Owner need? The list MIGHT include:
      > - documents and records required to pass an audit (code review records,
      > approval records, etc.)
      > - documents required to train and/or inform (user documentation, training
      > materials, release guide, etc.)
      >
      > 2) What documentation do the Developers need? The list MIGHT include:
      > - design specifications
      > - functional descriptions
      > - test plans
      > - test documentation
      > - database schemas
      >
      > It's also important to note that a lot of documentation (particularly
      > documentation driven by "templates") is only partially necessary. Find out
      > what is actually needed by the PO and the developers before you assume. If
      > you're not sure, don't write it -- better to find out you needed it and go
      > back to write it than to just keep writing something over and over because
      > you always have and you're not sure if you use it.
      >
      > As I said, I think you've captured the real essence of the question, Ron. I
      > hope you don't mind my refactoring it a little.
      >
      > Jim
      >
      >
      > On Jan 26, 2010, at 7:46 PM, Ron Jeffries wrote:
      >
      >> Hello, Joshua. On Tuesday, January 26, 2010, at 1:33:35 PM, you
      >> wrote:
      >>
      >> > I'm curious what you've found to be the best approach to Agile
      >> > Documentation.
      >>
      >> Write what the Product Owner wants, what the developers need, and
      >> nothing else.
      >>
      >> Ron Jeffries
      >> www.XProgramming.com
      >> www.xprogramming.com/blog
      >> Master your instrument, master the music,
      >> and then forget all that *!xy!@ and just play. -- Charlie Parker
      >>
      >>
      >
      >

      --
      Sent from my mobile device

      Jeff Anderson

      http://agileconsulting.blogspot.com/
    • George Dinwiddie
      Hi, Jeff, ... I didn t see anybody suggest that. James talked about needs, now wants. ... Multiple product owners? Are they not acting as one? If they re
      Message 51 of 51 , Feb 1, 2010
      • 0 Attachment
        Hi, Jeff,

        Jeff Anderson wrote:
        > Saying to write "just what the product owner and developers wants"
        > seems a little bit like hand waiving.

        I didn't see anybody suggest that. James talked about needs, now wants.

        > I'm rarely in a situation where we have just one product owner, and
        > even when we do the product owner needs advice on what to document.

        Multiple product owners? Are they not acting as one? If they're giving
        separate instructions to the development team, you've got another
        problem--one that documentation won't solve.

        Does the PO (do the POs) need advice on what the product is? If they
        don't know what documentation they need as part of the product, why were
        they made PO?

        > If you are in a sensitive field, you or your product owner may have
        > risk officers or security experts to consult, if you have a separate
        > support group someone better consult them on what they need to keep
        > this running.Its not just about developers and product owners.

        Even in large orgs with many stakeholders, the job of the PO is to
        funnel that down into one stream of essential work. If documents are
        /necessary/ to satisfy certain stakeholders, then they're necessary.

        > Sure
        > don't document to follow a process, but that doesn't mean you can't
        > offer some advice on some docs that help in certain situations.
        >
        > I tend to use (in the following order)
        > -tests (automated and manual)
        > -support and operation guides
        > -func hirerarchy (like epics and stories)
        > -platform and arch outline
        > -domain driven design style models (ie concise and compact)

        In what way do you use these? I understand tests and the guides (the
        latter which the PO should be specifying, if they're needed). When do
        you need the others? How much work are they to keep up-to-date as
        opposed to redeveloping them as needed?

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      Your message has been successfully submitted and would be delivered to recipients shortly.