Superpower your Agile process analysis with SIPOC & Pareto

SIPOC is a high-level process mapping tool that has existed since the 1980's. It is a lightweight systems analysis too, easy to understand and easy to complete. SIPOC is an acronym of "Suppliers", "Inputs", Process", "Outputs" and "Customers" and often pronounced sigh-pock. SIPOC can be used to understand an existing "as-is" process or to design a desired future "to-be" process. In the past we have used them as a pre-cursor to the following:

• Value Stream Mapping to identify the process steps before measuring Process Time (P/T), Wait Time (W/T) and Percentage Right First Time (%RFT).
• Event Storming where they can be the focus of an analysis to determine an intial architectural design,
• Designing Agile processes with process steps for Kanban and timebox and standard sub-task designs for Scrum.

The last of these is what the rest of this post will focus on.

The image below shows a typical SIPOC template in Miro but we often complete these on whiteboards, on flipcharts and even in presentation decks. To complete it we follow the numbered steps but can skip back and forth if an area is unclear or subsequent conversation reveals an element was missed previously.

Step 1. The What, Who and When. Our first step when running a SIPOC workshop is to determine what is the process we are analysing, who is responsible / accountable for it and when did it or will it start. The answers to these simple-looking questions can be revealing. For example, highly regulated industries may point to an external set of regulations that determine the software development process and an owner that is outside the development team. Changing these processes can be slower and more challenging than a new team in a startup who often won't have any title for the process and have no idea who is responsible for any part of it. When we are developing a SIPOC for a new Scrum team's software development process we prefer to make the team responsible for the process from the start date of Sprint 0.

Step 2. The Trigger and Terminator. Step two bounds the process by setting a trigger and terminator, the start and the finish. These have to be judiciously applied as there are often sub-processes within a core one and the one for this SIPOC is usually part of a bigger set of processes across the organisation. Each sub-process can be analysed with it's own SIPOC and care must be taken to determine both the start and end points. For Scrum we recommend the arrival of a new piece of work / request / PBI / ticket as the Trigger and the delivery of this work as the terminator. The advantages of this include:

• Alignment of Definition of Done to the terminator
• Ability to map how both planned and unplanned work will be handled. A process that starts just at sprint planning tends to focus too much on just planned work and omit unplanned work which is like focusing on preparing dinner and ignoring the Bengal tiger sitting in the corner drooling - it is generally unwise and unsafe to do so.

Step 3. The Customers / Process Consumers. Although the "C" denotes customers - it is better to consider all potential process consumers. This tends to include both end customers, downstream teams, auditors, process excellence etc. We recommend to do this closely with step 4 as there tends to be a bit of back and forth between generated artefacts and the consumers of each.

Step 4. Outputs. The outputs are the complete set of outputs generated by the process. For Scrum teams, outputs often include: working software, documentation, updated test harnesses, updated development pipelines, process metrics, updated customer feedback metrics, updated backlogs etc. It is not uncommon that as we proceed through the process itself new outputs and consumers appear. We recommend to never create a SIPOC in permanent ink - there can be a lot of updates and changes as it is being created.

Step 5. Inputs & Step 6. Suppliers. Once the Outputs and Customers are ironed out, it is usually a bit more straightforward to create the Inputs and Suppliers. In iterative processes, there tends to be a large overlap between the Customers and Suppliers but not necessarily the Inputs and Outputs. Remember items like feedback are inputs to a process.

Step 7. The Process. Although business process mapping techniques are recommended for the steps of the process in Step 7, in our experience a simple flow chart is often enough for the process. A good tip to know when the the process is complete is to make sure that the inputs and outputs have all been included / considered in the process steps. If one is not included then there is probably part of the process still missing.

For future processes the process steps will tend to be simpler. For an existing process, the steps taken can often get into a "it depends" trap. While real-world development processes are sensitive to situational contexts a useful technique we find is to use Pareto's Rule and look for the most common paths through the process first - the paths taken ~ 80% of the time. That is not to denigrate the remaining paths (Pareto himself cautioned that the remaining 20% could result in 80% of the issues encountered) but to focus on the more common ones. By doing so you can start to do a rough order of magnitude calculation of how long a sprint should be (by looking at the timings of common process steps) and create a list of common sub-tasks for use in Sprint Planning if you break stories into subtasks as part of your planning techniques.

In summary: SIPOC is a useful tool to analyse processes. Lightweight, easy to understand and relatively easy to master. It can help you and your team design appropriate sprint durations, predict frequent tasks, understand how your process works at a high level and provide inputs for more detailed subsequent analysis. Contact us if you would like to learn more.