Why use Rapid Project Documentation Language
After being in and out of meetings with never any clear definition understood between the business side not clearly able to communicate to technical and non-technical teams about their goals or needs as resulted in several attempts to write clear notes for what to do that never go anywhere.
Let alone being a rapid developer and a member of the agile community has lead to some best practices that to the layman seems a bit off putting.
Given that documentation these days seems to be the last thing any one thinks about but the one thing that must be done something had to be addressed.
What is Rapid Project Documentation Language
Thus lately Iβve needing to design a iconographic language for scrum and rapid project documentation. In my research Iβve used unicode, UML, and Extended Backus-Naur Form to help define a common language that both developers, layman, and business can understand complex problems and ideas without resorting to anagrams, marketeering or buzzwords.
For the curious try this Quick Key:
@ ::= Actionables
π₯ ::= Delta or Change
β ::= Constraint
β ::= Blocker
ο ::= Note (font awesome: https://fontawesome.com/icons/sticky-note?style=regular)
In testing its been found that this best paired with the Cornell Note taking system, GTD project Verbs, and Todo.txt syntax. At some point there should be an pwa/dapp for this or a site documenting how to use it in oneβs Bullet Journal.
A sample layout would consist of outline notes as:
ο Notes
- item one discovered in the meeting
- talking point two discovered or to be discussed
...
β Constraints
- constraints to consider
- constraints to implement
...
β Blockers
- blocking item 1
- stopping point two
....
π₯ Delta
- short idea on what could change
- short statement on what should change
- what must change
@office Make the things work due:01/01/19
@makerspace build cool things due:whenever #projectname
Additional resources