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

Re: [scrumdevelopment] Scrum and Documentation

Expand Messages
  • Amanda Abelove
    Chipping in from the professional services side of the house... Development documentation - you need to be in a collaborative workspace that helps you produce
    Message 1 of 8 , Jul 29, 2009
    • 0 Attachment
      Chipping in from the professional services side of the house...

      Development documentation - you need to be in a collaborative
      workspace that helps you produce this as a byproduct. Throw away MS
      Word, Excel and Visio.

      Divided by product category:

      Inhouse business services/tools:

      Look at something that manages product information using role-based or
      tag-based access levels. This can be a free plugin for Drupal/Joomla
      or all the way to Sharepoint.

      Consumer products and services:

      If you are just getting started, start with a blog and tagging... Look
      at social-driven tools for crowdsourcing solutions.

      If you are a legacy professional services department with product
      documentation as it's own set of offerings, you are probably stuck in
      the same set of problems as yellow-pages or newspapers. With the added
      headache of managing a consulting and training org.

      Look at collaborative workspaces that can facilitate technical teams
      and offer one-click publishing options for marketing departments.





      On Tue, Jul 28, 2009 at 8:30 AM, Xavier Quesada Allue<xavier@...> wrote:
      >
      >
      >> I'd like to start a thread on the role of documentation in a Scrum
      >> environment.
      >
      > Hmm, let's see. There are only 3 roles in Scrum: Product Owner, Team
      > Member and Scrum Master.
      > Which of these roles would you say documentation is best suited to play?
      > Maybe Team Member? I've seen many cases where Documentation helps out.
      > For example when you are doing the sprint demo and the projector is
      > aiming too low, Documentation steps in to help aim it higher.
      > Teamwork!
      >
      > Regards,
      > Xavier
      >
      > PS: Since some people might not appreciate the humour, a serious answer
      > below.
      >
      > In my view, Documentation in Scrum can be coarsly classified in 3
      > categories:
      >
      > a) Things the team feels they need for internal use, in order to
      > create quality software. For example they might want to maintain an
      > Entity-Relationship diagram of the database.
      >
      > These documents will be written by the team out of their own
      > initiative, as they consider them fundamental to doing quality work.
      >
      > b) User Manuals and any other documentation that is of understandable
      > and agreeable value to all, for example for maintaining the software
      > once everybody is gone.
      >
      > Careful with this: unless explicitly clarified as part of the
      > acceptance criteria for each story or as independent stories, this is
      > sometimes "forgotten", so it is the joint responsability of everyone
      > to make sure it isn't.
      >
      > c) Other documentation that is required because of some external
      > factor (official waterfall process, audit, compliance, etc) but that
      > is considered useless by the team for developing and maintaining the
      > software itself.
      >
      > This kind of documentation in Scrum is a deliverable that the Team
      > will make on the request of the Product Owner. Meaning: if the Product
      > Owner wants some documentation, she has to ask for it and the team
      > will build it. It is another backlog item like anything else (or part
      > of the acceptance criteria of a story, which boils down to the same
      > thing).
      >
      > When people say "agile teams don't do documentantion", what they
      > _really_ mean is "agile teams won't spontaneously do documentation
      > they don't need out of their own initiative". Just common sense.
      >
      > On Tue, Jul 28, 2009 at 4:33 PM, sjanvrinxx <sjanvrin@...> wrote:
      >>
      >>
      >>
      >> I'd like to start a thread on the role of documentation in a Scrum
      >> environment. I've realized I'm not sure I understand the "official" position
      >> regarding documentation.
      >>
      >> To clarify - I'm discussing product related documentation, not
      >> documentation of the Scrum process itself.
      >>
      >> To start the dicussion: what is the role of "traditional" IT development
      >> documents such as Business Requirements, Functional Specifications, etc., in
      >> a Scrum environment?
      >>
      >>
      >
      > --
      > Xavier Quesada Allue
      > Visual Management Blog
      > http://www.xqa.com.ar/visualmanagement
      >



      --
      -Amanda

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      310-237-6370
      Skype: amanda.abelove

      Scrum Club - A Scrum methodology user group
      @scrumclub, #scrumclub
      http://scrumclub.org

      Corporate Espionage - A tradable card game on entrepreneurship
      @corpespionage, #corpespionage
      http://masterofespionage.com
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Your message has been successfully submitted and would be delivered to recipients shortly.