Workflow Diagram

And Let the Diagramming Begin!

Like any diagramming process, there are various flavors of this document, but any work flow must cover six essential aspects per process:

1. When does the process begin? (If preceded by a specified process, indicate the name of that process.)
2. What happens during the process?
3. What determines that the process has ended?
4. What determines that the process has not ended successfully?
5. What is the next step in the process when completed successfully?
6. What is the next step when the process has not completed successfully?

The Work Flow Diagram should not contain a lot of detail, after all this is a diagram, and those boxes are just so large. – Ok, you can make them bigger, but why should it take the developer or stakeholder a half-hour or so, using a magnifying glass, to read the content of your boxes. Save the detail for your Use Cases. Keep your content brief.

Finally, here’s a quick word on the difference between a Workflow Diagram and an Activity Diagram. Workflow Diagrams are fairly flexible and easy to read. They don’t have a UML specification. Most companies seem to prefer such diagrams over Activity Diagrams. Non-technical persons have no problem reading these diagrams. However, even if a particular diagram is not defined by a UML standard, it adds a lot to the consistency of your work if you format non-standard diagrams according to UML specifications as much as it makes sense.

If, however, you are contracting with a client, such as the US Government who generally embraces UML standards, then I would still use the Workflow Diagram to get sign-off on the business process and then create the Activity Diagram as a way to begin the solution architecture. Activity Diagrams are more geared toward the developer and tend to be a bit harder for non-technical business persons to comprehend. They are defined by a UML specification.

Articles Additional Resources

These links should give you a solid overview of what a Workflow Document is and offer some helpful patterns.
Wikipedia article on the Workflow Diagram
Brief Wikipedia article on Business Process Modeling
Repository for Workflow Modeling Patterns
Windows Workflow Foundation


Business Process Workflow
Technical Process Workflow

About Larry

Larry Lawhead is a passionate Agilest with a love for coaching, mentoring and organizational transformation. Huge fan of the Lean Enterprise, LeSS, Theory of Constraints, systems thinking and of course the Toyota Production System. Avid learner. Deeply influenced by the works of Jeff Sutherland, Eliyahu Goldratt, James Womack, Craig Larman, Faith Fuller, Marita Fridjhobn and countless others. He is likewise a member of the team that brings the Agile Open to the Southern California. Above all else, he loves coaching teams and individuals. He believes creating a safe and empowered place for individuals and self-organized teams to develop brilliant solutions, shared vision, demonstrate compassion and desire to continuously improve brings life’s greatest rewards. Watching clients unfold into a greater sense wholeness, purpose and direction is the miracle coaching enables. This satisfaction leads to continuous self-improvement, curiosity and personal growth that Larry passionately embraces.
This entry was posted in Product Owner Stuff. Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.