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

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

Expand Messages
  • Ron Jeffries
    ... Perhaps. All of it fits on a single slide in Ken s slide pack tho. Ron Jeffries www.XProgramming.com www.xprogramming.com/blog I cannot find my duck.
    Message 1 of 51 , Feb 1, 2010
    • 0 Attachment
      Hello, Dan. On Monday, February 1, 2010, at 1:29:40 AM, you wrote:

      > From an estimation side, I won't disagree. However, from a "doneness"
      > perspective, I think there is information to be captured and moved forward.

      Perhaps. All of it fits on a single slide in Ken's slide pack tho.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      I cannot find my duck.
    • 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.