The primary reason to design and begin a workflow is to provide for ease of use. A team should design a workflow around their code base, allowing them to understand how to retrieve specific code, how to edit that code, and the impacts of the new edits. A workflow also provides a standardized way of packaging the code, to be delivered and used by the existing code base. Each step in the workflow should be clear, concise, communicated, and repeatable. It is important that everyone on the team understands not only how the workflow works, but why each step of the workflow exists, so that they can troubleshoot and contribute to the workflow, should something change in the organization.

One of the primary benefits of a shared workflow, as opposed to individualized workflows, is the ability to measure the impact of the workflow on the organization. To measure our workflow, we first separate standard and nonstandard units of work. The edits that we make to our code often vary in size and complexity, and are not easy to measure in standard units. On the other hand, code is generally checked out, tested, and deployed in the same way every time, leaving us with a good estimate of how long it will take to go through our workflow, minus the code edits. 

If our workflow takes about 30 seconds to clone the code repository, an unknown amount of time to edit code, 5 minutes to run a test, and another 30 seconds to deploy the code in our environment, our workflow, with a single test, will take about 6 minutes. If we have eight members of our team, who each run through this workflow 10 times a day on average, our workflow actually constitutes about 8 hours a week of our combined work (8 x 10 x 6 = 480 minutes, or 8 hours). Cutting this testing time in half reduces our total time as a team spent on the workflow by about 3 1/3 hours per week. Because of this measurable amount of time that can be saved in a workflow, a team should consider optimizing their workflow whenever possible.

Generally, you won't need more than a rough estimate of the time it takes to perform the standard functions of the workflow, but you will need to know which pieces might be performed more than once. With Puppet, a user will likely write, push, and test code more than they will pull it down. You can inspect each piece of the workflow separately and seek to improve a part of the process, but you should consider the ramifications of a change to the rest of the workflow.