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

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

Expand Messages
  • Thomasjeffreyandersontwin@Gmail.com
    Yes I agree, I usually capture the following on projects - operations and support anything my ops and support team tell me they need -1-2 pager on the major
    Message 1 of 51 , Feb 1, 2010
      Yes I agree, I usually capture the following on projects

      - operations and support > anything my ops and support team tell me they need
      -1-2 pager on the major functions, ie use case briefs, not detail
      - detailed, (and hopefully automated test case) at the business level using something like fitness ( typically in bdd style)
      - domain models, sometimes as CRC cards, sometimes in UML. I try to keep these in sync with the code, or in case of cots development, with the tests.
      - non functional expectations( volume, response time, security, etc)

      - platform choices, ie tools, libraries, version nums, etc...
      - user manual where appropriate
      - developer docs where teams are building code for other teams to use

      I try to use wikis wherever possible for my documents, that way the artifacts can be very focused, repitition is reduced, and a larger team can share the burden of documentation.

      Also many of these docs are optional (exept the tests) and depend in the scale and size of the project. I also try to keep it breif 1-2 pagers are good enough, and have a chance of staying up to date.

      On Feb 1, 2010, at 1:29 AM, Dan Rawsthorne <dan.rawsthorne@...> 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.

      Dan Rawsthorne, PhD, CST
      Senior Coach, Danube Technologies
      dan@..., 425-269-8628

      Thomasjeffreyanders ontwin@Gmail. com wrote:
      > My experience has been that guestimation backed up by some mental
      > modeling is going to get you the same accuracy as any amount of
      > historical documentation.
      > If your team is delivering and estimating in short cycles they will
      > get into a rythm andget very good at it.
      > Once the team change and or significant tech changes then old
      > estimates don't help as much.
      > Problem with using past history to do really accurate estimates for
      > future work is typically much of the context is no longer relevant ,
      > you might as well go with your gut, it better yet go with a bunch of
      > peoples guts (planning poker anyone?)
      > Jeff Anderson
      > agileconsulting. blogspot. com <http://agileconsult ing.blogspot. com>
      > On Jan 31, 2010, at 11:06 PM, Roy Morien <roymorien@hotmail. com
      > <mailto:roymorien@hotmail. com>> wrote:
      >> Hi Jordi,
      >> What information do you extract from those task tracking post-it notes?
      >> Especially what information do you extract that will assist you in
      >> estimating the current project, and the User Stories, and the tasks
      >> once they are moved into the Sprint Backlog?
      >> Regards,
      >> Roy Morien
      >> ------------ --------- --------- --------- --------- --------- -
      >> To: scrumdevelopment@ yahoogroups. com
      >> From: jordi.salvat. i.alabart@gmail.com <http://gmail. com>
      >> Date: Thu, 28 Jan 2010 17:12:22 +0000
      >> Subject: [scrumdevelopment] Re: Best approach to "Agile Documentation"
      >> Hi Ron.
      >> We do that pretty often by retrieving the task tracking post-its
      >> where we logged hours spent. It's free, since we want to log hours
      >> anyway for other reasons. And it saves time and mental energy during
      >> planning. Mental energy at planning time is a very scarce resource
      >> for us, as our planning sessions are really exhausting.
      >> Of course it can only be used successfully for very similar product
      >> items, but those come up all the time in most software products
      >> (certainly in our's).
      >> --
      >> Salut,
      >> Jordi.
      >> --- In scrumdevelopment@ yahoogroups. com
      >> <mailto:scrumdevelopment@ yahoogroups. com>, Ron Jeffries
      >> <ronjeffries@ ...> wrote:
      >> >
      >> > Hello, Roy. On Wednesday, January 27, 2010, at 10:58:16 PM, you
      >> > wrote:
      >> >
      >> > > Another interesting qestion, for me at least, is about the use of
      >> > > project histories (written documentation perhaps) for use to guide
      >> > > future estimating. A lot of people talk about recording their
      >> > > project experience so they can estimate better in the future. S
      >> > > what about this 'documentation' ? What is it? Is it useful? How
      >> > > best is it recorded and organised? etc.
      >> >
      >> > In my long history I have /never/ seen this done. My guess on why is
      >> > that it's clear to most people that it isn't useful.
      >> >
      >> > Ron Jeffries
      >> > www.XProgramming. com
      >> > www.xprogramming. com/blog
      >> > My advice is to do it by the book, get good at the practices, then
      >> do as
      >> > you will. Many people want to skip to step three. How do they know?
      >> >
      >> ------------ --------- --------- --------- --------- --------- -
      >> Sell your old one fast! Time for a new car?
      >> <http://clk.atdmt. com/NMN/go/ 157637060/ direct/01/>

    • 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
        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.