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

RE: [scrumdevelopment] Functional and technical documentation.

Expand Messages
  • Roy Morien
    Well, if you must do all those documents at the start, and that is the mindset that you have, then I suggest you don t use Scrum. Clearly you will have to have
    Message 1 of 22 , Jul 30, 2009
    • 0 Attachment
      Well, if you must do all those documents at the start, and that is the mindset that you have, then I suggest you don't use Scrum.
      Clearly you will have to have some documentation, but you must closely examine the purpose of that documentation. If it is basically to tell people what they must do, then it is not very useful; there are other and better ways to communicate this information.
      I have always been very sceptical about the need to document in any detail what the old system does. Pobably for the first time in its sad and tragic life this is the first time it has ever been documented, just in time to throw it away.  So what is there in the old system that can actually valua
      I am sure that you can spend some time looking at the old system at a reasonably high level and create a set of User Stories for future development. That is, if ploughing through the old system will really reveal anything useful for the new system. Usually the old data has to be understood, but then new data structures must be created for essentially the same data, but in a much more orderly and well designed fashion. That activity will also tell you what you have to do to salvage that old data, and insert it into the new data structures. This (to me) is a relatively simple ER Modelling and DB Modelling exercise. Others may follow an OO Analysis path. You can fill out the details of this as you go through the iterative cycle. There is no need to have the whole data architecture fully detailed at the start (as seems to be your intention, if I am reading you intention about 'architecture diagram/document' correctly.
      In all probability your GUI and browser interface will have no resemblance to the old interface, so documenting that will be futile. The new interface will be developed according to your new standards, and can again be developed in an iterative fashion. Basically, the new interface is a 'green fields' development, I would suggest.
      WHat else can you salvage from the old system, that you might want to document? Well, only any special processing rules. Will you develop in the same language? If not, then most of the processing code will not be very useful to you. Different procedures and functions, in a different language, so there is no value in documenting that.
      Why are you worried about changing scope? Do you really think you can have it all detailed 100% at the start, and there will never be a requirement for a change? Are you really saying that you will refuse to learn anything new once you get past that big documentation stage? No way, brother!! And this is not Scrum!! This is traditional thinking. I see that you are concerned about 'change management and scope creep'. Well, in Scrum and agile methods generally, this is not a concern, but a part of daily life. This is handled quite easily and simply by having the Product Backlog under the control of a Project Owner who is frequently updating it as to content and priority etc. Again, it seems that your thinking is not Scrum, but very traditional.
      Documentation is always important, but what documentation? If you are creating documentation with what I might call transient information (ie: that is information that can be used and then discarded in te very short term) then it is probably easier just to talk to people about it, rather than documenting it. If it is documentation for the purpose of informing people in the long term ... those generations of programmers as yet unborn ... then sure, document it. If it is documentation that is likely to become irrelevant or incorrect during the period of the project, then I would ask if it is being prepared too soon ... some just-in-time thinking here is appropriate.

      To: scrumdevelopment@yahoogroups.com
      From: bmithun@...
      Date: Fri, 24 Jul 2009 07:34:30 +0000
      Subject: [scrumdevelopment] Functional and technical documentation.


      I am working on a new project in which I will play the role of a SCRUM master. We are in very early stages of the project. The goal of the project is two fold, A) one to re-write an existing 10 yr old web application and B) other is the simplify back-end processing (merge\eliminate around 30\40 console\windows application used for processing).

      The artifacts we have been provided are the web site only for effort A and couple of visio's and DB backups for B. We also have SMEs at the client site with whom we are meeting and talking regularly.

      I am trying to figure out the best way to plan for the documentation tasks. Here is the documentation I want to create:
      > Current state\our understanding documentation
      > Requirements - this is a must for change management and scope creep
      > Architecture diagram\document
      > High level and Low level design documents

      Questions and thoughts in my mind:
      > Should I wait to start the sprints till I work on these documents?
      > Should I include these documentation tasks as part of the sprints? if yes, what percentage of completion should I target for in the first sprint? I think this will drive the number of folks working on the documentation.

      General questions:
      > How is documentation planned generally in Scrum? None of the sites I read talk about the documentation.
      > How is scope creep and change management managed in a fixed bid project? While it is good that client gets a chance early on for viewing the product and suggesting the changes, I am worried that this might add new scope.

      Thanks for reading the long post and thanks in advance for responding :).

      Sell your car fast. Need a new model in your life?
    Your message has been successfully submitted and would be delivered to recipients shortly.