Introduction
We have other resources available on how visual models are great in an agile environment and which visual models have the most impact on requirements for an agile team. However, we often get requests for additional details on how to utilize visual modeling on an agile project.
This short paper series, “DeepDive Models in Agile”, provides valuable information for the Product Owner community to use additional good practices in their projects. In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.
The first in this series is the Process Flow. Other editions in this series will include: Business Data Diagrams, State Tables/State Diagrams, Decision Trees/Decision Tables, Business Objectives Models, and Feature Trees. You can always send a comment to [email protected] if there is another model you are particularly fond of hearing how it adapts to agile.
What is a Process Flow?
A Process Flow is an RML People model that describes the steps that a user takes to accomplish a goal or finish a task. This model is great for understanding the project’s current and future state processes of the business and understand those processes from the end user’s point of view.
RML Process Flows are created in levels in order to both be able to see the big picture of a process within a system as well as drill down into the details of a single more detailed process. This is in contrast to huge process maps with over 100 steps that try to show it all – but are unreadable! At the highest level, generally called the L1 level, the entire end to end process for an end user in a system is described, usually in 7-10 steps. This level tends to have no swim lanes or decisions to be made, so it is very abstract. See the top row in the example below:
From there, each step in the L1 process is broken down into the lower level processes, called L2 and L3 Process Flows. These are the levels that most people are comfortable talking about and eliciting. Each L2 or L3 process should be no more than 20 elements to keep readability, and even then should be divided by swim lanes to create smaller groups within the diagrams. L3 Process Flows are usually optional and are used if the process is large or complex of if there is a need to elicit that lower level of information to create requirements. See the example of an L2 and L3 Process Flow above.
When would I use a Process Flow on an agile project?
Process Flows are usually used for user facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic.
When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.
Once in the developing phase or in the sprints themselves, the PO or BA will look ahead (usually 1-2 sprints ahead) and determine if additional L2 or L3 Process Flows need to be built to ether identify new stories for upcoming sprints or elaborate (via L3 processes) those stories already identified.
This can continue until the project ends. Additionally, the PO or BA, when doing their planning for upcoming sprints, may need to update existing L2 or L3 Process Flows with new information that has come to light. In this case, that time should be built in as part of elaborating the stories and a common set of Process Flows should be kept so that they are up do date!
How do I create a Process Flow?
Process Flows are one of the easier RML models to elicit and create. To elicit the information, the BA or PO should discuss with the users and stakeholder the processes in the system today, who performs them, and when. Users tend to naturally think about the steps they take every day so this is usually a pretty easy model to elicit.
During elicitation sessions, you can bring draft or strawman models, to generate commentary and ideas. You can also start from scratch with a whiteboard, post-it notes, and the users to create the process.
For future state, the PO or BA will generally start with the current state process flows and elicit information from the users/stakeholders on what will change or be different in the future system.
The Process Flow model itself for RML has roughly 7 element types, of which, we’ll only cover 4 or so today. The elements we are not covering here are forks, joins, and events. All of the elements are connected together by lines with arrows that show the direction of the flow.
Step - The step is the most used element, as it is contains all the process steps. This is typically a rectangle with short phrases in the form of subject-action-noun phrase (User logs in). These sentences should be kept short to get the point of the step across without understanding every nuance.
Decision - This element is typically shown as a diamond and describes a decision the user must make to move forward in the process. Decisions are most commonly binary (Yes/No), but can be non-binary as long as the options are all mutually exclusive and collectively exhaustive. Every decision diamond needs at least 2 options coming from it to be a decision.
Swim lanes - Swim lanes describe either the user or group of users who performs the steps or the system in which a series of steps or decisions are taking place. The swim lanes for a single process flow should be all of one type (either user or system) to enable easier understanding. Swim lanes are a way to organize the steps in a Process Flow to focus attention and save space by not having to repeat the user or system in each step.
Incoming/Outgoing Elements - Since RML Process Flows are built in levels, every lower level (L2 or L3) Process Flow should have an Incoming and Outgoing element. These elements are the “You are here” for the Process Flow set. They tell you what process step immediately preceded the current process and where the reader will go next.
How do I derive user stories out of Process Flows?
Once the PO or BA has good draft Process Flows to work with, he can start deriving stories out of the Process Flows to build or add to his backlog.
The level of story derived depends on the level of the Process Flow and the complexity of the process. In most cases, each step in an L1 Process Flow becomes at least one Epic user story (too big to fit into a single sprint). Each step in an L2 or L3 Process Flow becomes one or more User Stories for the backlog and each decision can be as few as 1 user story or as many as 7 user story. See the examples below.
Because user stories are written from the user’s point of view and Process Flows are created from the user’s point of view, Process Flows lend themselves very easily to identifying user stories. For example, if the Process Flow step is “User logs into the system,” then the user story is very similar and might look like “As a User, I want to be able to log into the system, so that I can access my account information.”
Decisions are a little more confusing because if it is a lower level decision (say in an L3 Process Flow), it might be one story with the decision lines being acceptance criteria. If it is an L2 Process Flow, the decision might lead to a story for each branch of the decision diamond. For this, the PO or BA will have to use her knowledge of the team and the process to decide what is best for slicing up the stories.
Conclusion
Process flows are one of the easiest RML models to derive user stories out of because they are from the user’s point of view and allow the PO or BA to walk through a process systematically and write user stories for each step that needs to be supported.
However, one final point is that these Process Flows don’t need to be perfect or complete to be useful. The PO or BA can draft a process flow, review with users or stakeholders, and derive user stories from an incomplete one. As long as there is traceability between the process steps and the user stories, it is easy to know what to update if the process changes or where the gaps are if new steps are added. Additionally, even team members other than the PO or BA can edit and update the processed if they live in a centralized location.
In the end, these are one the most useful models we find on customer facing agile projects because they are quick to make and update and lend themselves very easily to stories at all levels of the agile requirements hierarchy.
Author: Candase Hokanson, Senior Product Manager at Seilevel
Candase is a Senior Product Manager at Seilevel and a PMI-Agile Certified Practitioner who trains and coaches product owners, scrum masters and business analysts on agile approaches as well as championing products in those roles for clients. She works with teams to unite every team member around the common end goal of delivered business value to save up to millions of dollars in development costs for features that won’t be used or that don’t contribute to the anticipated business value. She also works with clients to help scale their agile practices beyond one team or one pilot to the entire organization.