We’ve seen organizations abandon or neglect visual modeling when they make the shift to more Agile development processes, but in our experience, models definitely play an important role in product design no matter what your organizational processes are! Let’s dive into a deeper look at that most ubiquitous and useful of models, the process flow, and see just how it fits into the world of 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 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 maintain readability, and ideally should be divided by swim lanes to create smaller groups within the diagrams. L3 Process Flows are usually optional. They 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 should I use a process flow in Agile?
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.
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 phase. From there, 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 product development phase, 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 either identify new stories for upcoming sprints or elaborate 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 up do date!
How do I create process flows?
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 work with users to create a flow from scratch with a whiteboard, markers, and post-it notes (or an electronic whiteboard for virtual sessions).
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. If you’re developing a brand-new process, this is more of a brainstorm than an editing session.
The process flow model has several types of elements. All of the elements are connected by lines with arrows that show the direction of the flow.
- Step – The step is the most used element, as it 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 statements should be kept short for readability – they won’t convey 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 stories from process flows?
Once the PO or BA has good draft process flows to work with, they can start deriving stories out of the process flows to build or add to the backlog.
The level of story derived depends on the level of the process plow 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 story for the backlog. Each decision can be as few as 1 user story or as many as 7 user stories. See the example backlog 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 read: “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 their knowledge of the team and the process to decide what is best for slicing up the stories.
Wrapping it up
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 important 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, team members other than the PO or BA can edit and update the process if they are stored 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.
