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

RE: [scrumdevelopment] documentation using Scrum

Expand Messages
  • Mike Cohn
    First-In my opinion, Scrum has no adamant opposition to documentation. It just depends on what the document is. (XP seems far more opposed to documents than
    Message 1 of 2 , Mar 21, 2002

      First—In my opinion, Scrum has no adamant opposition to documentation. It just depends on what the document is. (XP seems far more opposed to documents than Scrum, which is why I think Scrum scales up better, or at least adds enough to XP to let XP scale up.) If a document adds sufficient value I don’t see any reason not to do it (or part of it, more likely). A document may add only the value of having your boss not fire you—and that may be a good enough reason to do the document, at least as the team gains experience with Scrum.


      But—skip the in-depth requirements and design docs. The analogy I think of it with is that when I’m driving I can only see cars coming at me a certain distance away. Someone with better eyesight and brighter headlights may see the cars coming at him from farther away. A 16 year old who is just learning to drive is normally looking about 10 feet in front of his or her car—“What do I need to avoid right now?”  Most programmers/designers are only able to see the problems coming at them that are a very short distance ahead. This means people aren’t great at anticipating the requirements way in advance and even if they are then the implications of the more distant requirements cannot be fully thought through. In most cases thinking too far out is not productive. Of course it may help to have some hint of what’s coming. For example, I’m working on a project right now that will run on pretty much any handheld wireless device out there. We started with the Palm because it was easy and the emulator comes with the Java micro edition. It would have been shortsighted, however, if I’d started with the Palm and wrote in a proprietary way for just their device instead of using Java and making sure that all my target devices run Java. So, that’s one example of a requirement to think about well in advance. But anything about the specifics of the application we defer until closer to implementation time. I’ve found that it is generally good to keep a product backlog that is probably 3 sprints (usually a month each) worth of backlog. That way you are working on high priority work and not just what the product manager thought of yesterday (but will decide is less important in two weeks).


      In terms of what I do for requirements, it sounds very similar to what you have already done. I go back and forth on using Project or Excel. Right now I tend to favor Excel because of better text handling capabilities and it helps avoid a tendency people have to ask you to fill in the date columns in Project when they see it. Let me know if you’d like and I can send a snipped down version of such an Excel sheet for a current project. I don’t want to clutter the list with an attachment though (even a small one).


      As to higher level requirements I’ve had success referring to these as “characteristics” and I usually create an “Essential Characteristics Document” (or ECD). The difference to me is that a characteristic is what a marketing person would call a “requirement” while a “requirement” is what a techie would call a requirement. A true requirement is an IEEE 830 style (although not documented that way!) requirement, “The system shall support faxing of daily detail records to up to 3 configurable fax numbers.”  A characteristic might be “Support for faxing”.  Another way to think of characteristics is that they are the bullet points on the box at CompUSA (figuratively, even if it’s not a commercial product). I’ve found it useful to do an ECD because it helps make sure everyone gets on the same page about what the product is really doing and it helps put some scope around how big the project will really be. It doesn’t scope out the project duration, the team size or anything like that but it just gives you an overview of what you’re building. The ECD is the ideal document to give to a new team member a few months into the project. Another way to think about an ECD to help make sure you don’t create an IEEE 830 SRS instead: The ECD should be enjoyable to read (“OK, that sounds cool—let’s get coding!”) whereas no one enjoys reading an SRS or even a huge pile of use cases.


      My ECD template has the following organization:

      Table of Contents

      Revision History

      Document Overview

      Product Overview

                  Included Features

                              (the meat of the document: a list of very high level characteristics (“support for faxing”)

                  Optional Features

                              (Things the product management group wants to mention and want eventually)

                  Excluded Features

                              (Odd but it’s useful. Sometimes there is a lot of talk about a product for months (years!) before it gets coded and sometimes it is worth listing what is not going to be part of the product (e.g., “No OS/2 Support”))

                  Non-Functional Characteristics

                              (OS, machines, etc.)


                  (most useful in outsourced on internal work—what will be delivered as part of the project. For in-house work this may be the creation of a deployment environment (servers, databases, etc.) beyond just the new software

      Noteworthy Risks


      This sounds like a lot but in should be less than 10 pages (most people have a hard time being that terse) and it should be easily written in a day. For projects I’ve been involved the one day spent here pays back later by avoiding misunderstandings, usually with key stakeholders who aren’t in the day to day scrum activities but who would receive the ECD at the start. As with the Excel, if you want a copy of my ECD template, let me know and I’ll get it to you.




      PS: I looked up your website (dog training collars). Perhaps we can find a derivative of Scrum for training dogs? We put all the dogs in one room, have them self-organize and then pair up to train themselves.




      -----Original Message-----
      From: jelundatdst [mailto:jelund@...]
      Thursday, March 21, 2002 10:57 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] documentation using Scrum


      My team is in the processs of our first sprint, and I am getting
      inidated with requests for documentation. I, traditionally, am also
      used to spending weeks and weeks up front developing a in-depth
      requirements and design document.

      However, using Scrum, I have not been concentrating on this detailed
      of documentation. My documentation efforts have been limited to
      Microsoft Project (maintain a bullet list of current tasks in sprint
      and the backlog).

      Yesterday I sent an email to a Scrum website about documentation. Ken
      (could this possibly be Ken Schwaber the author?) responded back
      telling me to do a more high-level requirements document listing out
      the main objective.

      Do any of you have an outline per se (or examples) of a requirements
      document like this?

      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    Your message has been successfully submitted and would be delivered to recipients shortly.