0

It sounds strange, but that's what I need. An effective way to document a Scrum project.

I agree that it's a waste of time to produce User Stories and a Requirements Documents.

But sometimes we need to have the vision of how the software currently works.

How do you do that? Do you know some best practices or case scenarios on this?

Thanks

Montag451
  • 1,168
  • 3
  • 14
  • 30
armandomiani
  • 732
  • 6
  • 16
  • 4
    I'm voting to close this question as off-topic because [project management is now off-topic on Stack Overflow](//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website-to-ask-about-project-management-issues/343841#343841). Ask these questions on [SoftwareEngineering.SE](//softwareengineering.stackexchange.com/) and [ProjectManagement.SE](//pm.stackexchange.com/) instead. (Unfortunately, this question is too old to be migrated.) – robinCTS Oct 29 '17 at 17:15

3 Answers3

2

The short answer is this: you can write anything you want or need to about any project, Scrum or otherwise. Scrum doesn't tell you how to document, but it doesn't tell you not to. The way you document is in itself irrelevant to Scrum.

That said, if you need to understand how the software currently works, a document will not help you. Documentation often lies. If you're trying to understand how the system works, a document will only tell you what people think or want to believe is the truth.

What you should consider, is to use executable specifications and Test Driven Development to prove that what you believe the software does is actually true. automated tests combine documentation, examples and regression tests all into one offer.

Assaf Stone
  • 6,309
  • 1
  • 34
  • 43
  • I liked the 'executable specs' solution. TDD surely will be important and part of the docs, but I can't count on this. This new module will evolve 3 different systems (1 new ruby on rails and 2 old legacy hardly-testable .net) . – armandomiani Oct 18 '12 at 17:45
1

There are several kinds of documentation that can help you. It depends on your context which ones you need, and at what detail level. You could also use a tool such as MOOSE to create project specific visualizations of your software at all levels. Some simple documents are:

Stephan Eggermont
  • 15,847
  • 1
  • 38
  • 65
0

If you've tracked your product backlog items through completion, including acceptance criteria for each you should be able to point to the list of completed product backlog items as documentation. Everything you've programmed should be associated with a PBI, so the completed PBI's document your project.

Andrew Clear
  • 7,910
  • 5
  • 27
  • 35