Do you document/update processes before sending "Done"?

<introEmbed body={<> Often while doing a task, you follow a process. If it's a repeatable task, it's important that the process is documented and up-to-date. Otherwise, the next person to do the task won't know the right thing to do. The job is **not done until it's documented** - documenting/updating a standard is part of the ["Definition of Done"](/definition-of-done) in such tasks. </>} />

When should you do it?

Document or update a process as soon as a change happens. Don't wait until the task is complete because it will likely be forgotten.

Say a meeting where multiple options were discussed and a decision was made. You must communicate the client and the team, but before sending a 'Done', make sure the decision and its reasons are documented and accessible by others who didn't attend the meeting (e.g. Create or update a rule). This way others may not need a meeting next time.

If you are really under the crunch and your task is critically urgent (e.g. Production website is down), then send yourself an email to action the standard update later.

Where should you do it?

Processes are usually stored in different places depending on the context they apply to.

• Wiki or Repo - If related to a project
• PBIs - If related to a task being worked on
• Rules or blogs - Public standards and best practices
• Intranet - Internal standards
• Induction (e.g. SugarLearning) - Links to standards/rules + test knowledge