How is good documentation done using SCRUM?

Asked

Viewed 5,470 times

5

I am developing documentation using the agile method SCRUM, I do not know if I am on the right track, and many people have difficulty in this, so I decided to realize such a question, currently put in the documentation:

  • Introducing: summary of what the system will be.
  • R. Functional (Product Backlog): list of everything the system should do.
  • R. Nonfunctional: what the system should have to work with. Example: PHP version, database, framework.
  • First Sprint:

primeira sprint

In that sprint put what requirement it will meet, in addition to the planning of the Master made with activity diagrams and classes.

These were the topics I put up until then, making the second sprint only when you finish the first one (because it’s just me in the project).

The question is, which points a documentation using the SCRUM should have? The main topics to be exposed and how to expose.

P.S: In the case of diagrams, there should be class diagrams of the automated tests?

software-engineering documentation scrum
  • 3

    I’m not an expert on the subject, but I think the idea of using an agile methodology is not to waste time using UML and creating all its documentation (diagrams). The idea is basically to annotate the customer’s needs, put in the backlog, verify implementation priority, implement and present the result. Repeat this cycle until the system is ready.

  • @Mauhumor I believe this is a non-binding criterion, in some places they are used and others are not. When I saw this article, that’s what I meant, taking it as an option, I decided to add these two. But also not sure kk for that question

  • Yes, yes, SCRUM is not a religion that should be followed to the letter. You can adapt your need. But by doing a very extensive documentation, you lose agility, which is one of the objectives of agile methodologies. But if really this documentation will be needed later and the requirements are well defined. So that in the middle of the project the client will not ask to modify everything. I see no problem in mixing with UML.

  • really, if it is well exposed the use of diagrams can become useless.

  • It may or may not be. The client asks you to change something and gives you a short deadline. Will you update the documentation, or go straight to the code, will you have time for that? It will take some experience time for you to realize what is really useful or a waste of time. Especially when you need to rely on documentation for repairs, or assign another programmer to work on the system.

2 answers

8


Hello, Ivcs!

I’ll try to answer the question "How is good documentation done using SCRUM?" by answering something more generic like "How is agile documentation?" OK? I’ll try to be very informal and talk very simple...

First of all, it is a myth to say that agile development models completely abandon documentation. They just rationalize the creation of documents in order to do things with REASON.

Another detail is the difference that is made in agile model is between document and model (diagrams). A document has several models, but you should not create a model necessarily to document, because you can create a model just to reason or facilitate the explanation about something very specific.

You don’t create a class diagram like the one you did just to put in the document, you will create when you need to explain something to someone on the team or even just to think about relationships. What’s more, this modeling doesn’t even need to be a heavy weight process, full of use of state-of-the-art CASE tools, a simpler tool can be used (or even paper drawing =D).

Note that in classic models everything revolves around documentation (key piece in these models), even creating models just to document and document only by mere formalism. In agile methodology the document loses importance (but it is not abandoned!!) and you have a thought called "agile modeling", where you do not model to document, but model because you really need for a very specific purpose.

No document is created by creating in an agile development. You create a document...

  • Why the customer requested
  • To define a contract model (in such cases more detailed documentation is required)
  • Supporting communication with an external group
  • Reason

An agile document:

  • Maximizes the return of customers
  • Lean and economical
  • Has a specific purpose
  • Describes information that is less likely to change
  • Contains only "good things to know"
  • Have specific client and facilitate the work of this client
  • It is accurate, consistent and detailed
  • Sufficiently indexed
  • 1

    It helped a lot, they were things I knew, but as I learned agile method half wrapped with heavy documentation I ended up getting in doubts, but his reply was very clear and took the doubts, thanks.

3

Because it is an agile methodology, Scrum is part of the presupposed that the team is pro-efficient, that is, it can produce the maximum value with the minimum of artifact when talking about documentation. This generates confidence and consequently generates results.

Being agile and constantly evolving, a project within Scrum cannot have extensive and complex documentation, even because it goes against the pillars of the Scrum: Transparency -> Inspection -> Adaptation.

The documentation used for a Scrum project is usually composed of:

  • User story
  • Requirements
  • Diagrams

In summary, it is a more streamlined documentation with the client’s language and as objective as possible.

Note: It is important to remember that the "Product Owner" will always be present during the project to clarify any questions the team has about the documentation.

Browser other questions tagged software-engineering documentation scrum

You are not signed in. Login or sign up in order to post.