By default, the simulator is based on a kanban board, with 5 stages – Backlog, Analysis, Development, QA and Deployment. You have a team at your disposal that you can configure as you will. You can manipulate headcount, productivity in each activity, limits of WIP, new tasks strategies, pair programming (or mob programming), multitasking and so on. Some metrics are available, like basic WIP/Lead Time/Throughput and CFD.
Simulator – Main View
The main view consist of few sections:
- Top bar, with start/pause/stop and speed controls on the left and help and settings buttons on the right.
- Main board, where are tasks are rendered according to their current placement on the board.
- A bar with basic statistics.
- Tabs at the bottom, with various diagrams that let you see how the system behaves in time.
There is a window with almost all settings available by clicking on a wrench in upper right corner. The window consist of tabs grouping particular settings into logical groups, like Team, Board etc. Most settings are saved immediately after changing the value. There is one exception – Board settings. Board settings tab has a special button to save the new board configuration and reload the simulation.
If you want to limit WIP in columns, you can do it directly on the board in the main view.
You can configure your team by navigating to the Team tab in settings window.
There are two global settings and section that lets you configure particular team members. Global settings are:
- Max WIP for a single person – how many tasks one person can work on in a given time (multitasking). When a person is multitasking, she can’t work in pairs or do mob programming.
- Max no. of people working on a single task – a simple pair programming simulation, with possibility to set more than 2 people per task (mob).
The “Team members headcount and productivity” section lets you configure in details how your team is built. The table consists of rows, that represent roles in your team. You can define as many roles as you want. Each role is defined by:
- Headcount – how many team members there are in the role
- Columns representing productivity in each activity. Activity is defined by a row in a board, that is not a queue. For instance, if you have a Development Doing and Development Done columns and Development Done is a queue, there’s an activity “Development Doing” that needs to be worked on for each task (see Board configuration help for more details). Productivity is represented in %. If you set productivity to zero for some activity, people in this role will not be working on this activity at all.
Note – there are no penalties currently when pairing or multitasking, as well as no benefits of pair programming. If two people are working on one task, their productivity sums. When one person is working on multiple tasks, her productivity divides equally.
Task assignment rules
Team members assign themselves according to the following rules:
Starting from rightmost column:
- Order members and their skills in descending order, ie. find a person with the highest number in any activity at top, then find a second highest skill and person, and so on. If there are more than one activity available (like development and testing for instance), the person may appear in a list in a pair with the other activity. If a person has the same levels of skill in more than one activity, order them in such a way so activities that are later in the flow are higher on the list.
For instance, if there 2 activities (Development and Testing) and two team members (with the first having Development on 100 and Testing on 50 and the other Development and Testing on 50), the list might look like this:
- First – Development (100)
- Second – Testing (50)
- First – Testing (50)
- Second – Development (50)
- Assign members who have nothing to work on to task that are available (ie. no one is working on them). Iterate over the list from the first step and try to find task to a person in respective activity (in our example, try to assign First person to Development, then the Second in Testing and so on).
- Sort members ascending according to the number of tasks they work on, no higher than the limit “Max WIP for a single person”. Try to assign them to free tasks (multitasking) using the algorithm from the second step.
- If there are not working people available, try to assign them to the tasks that are multitasked the most (using the algorithm from the second step).
- If there are not working people available, try to assign them (using the algorithm from the second step, of course) to tasks occupied by others. Start with tasks with least number of people working on them.
You can change WIP limits for columns with a textbox next to the activity name
Removing the number from the textbox means “no limit”. Be careful, as you can hang the simulation in some situations when there’s no limit to WIP.
Limits can be set for groups of columns as well as separate columns. When setting a limit for Backlog, if the demand is high and there are more tasks to do than actual throughput, tasks over limit are dropped and counted. This happens after prioritisation algorithms kicks in.
You can configure the task spawning strategies in “Backlog” tab in settings.
There are two categories to configure here:
- Task creation strategy – when tasks will be created
- If Limit Allows – create as many tasks as limit allows. If there’s no limit for backlog column, use 1 as a limit, so the simulation not hangs because of infinite number of tasks.
- Constant push – spawn a new task according to the demand, that is configurable. Tasks are created in regular time periods; for instance when the demand is set to 8 tasks per day, the task will be created exactly every 1h.
- Random push – create a task or a batch of tasks in random moments, but according to specified demand level and expected batch size. The probability of spawning a task in a given moment is determined by probability calculated from demand level and batch size. The batch size is calculated using a normal random number generator with variance set to mean of batch size divided by 3.
- Scrum – create a batch every n days. The number of days and the batch size are configurable. Additionally, you can check a flag to substract from configured batch size number of tasks already on the board. For instance, if you set 100 as the number of tasks per iteration and at the beginning of the iteration there are 12 tasks still progressing, spawn only 88 tasks in backlog.
- Task size strategy – how big the tasks will be
- Constant – each task has the same size and you can configure it.
- Normal – each task has a size generated with normal distribution (only positive numbers are used), with means and variances configurable.
- S/M/L/XL – 4 types of tasks are created – small, medium, large or extra large. For each size type you can set its total effort in hours (3 hours means it should take around 3 hours to actively work on the task in all columns) and probability of spawning it. Additionally, you can configure how the total effort is divided to activities (in %). Finally, when task is created, its effort for each column is generated used normal distribution with variability = mean/2.
In the “Backlog” tab you can also configure how tasks are prioritised in queues, ie. Backlog and other queues if present.
This feature sorts tasks in a continuous manner according to the selected rule. Top tasks are those of higher priority and taken first to be worked on, so the sorting method is important. This highly influences which tasks are dropped when there are more tasks than WIP limit in Backlog column.
There are three options available:
- FIFO – first in, first out. No sorting basically.
- Value – tasks of higher value (Cost of Delay) go first.
- CD3 – Cost of Delay Divided by Duration – the higher the value divided by the remaining effort, the higher the task will end on the list
There are 3 options available:
- Basic metrics – WIP count, Throughput, Lead Time, WIP/Lead Time relationship (which should equal Throughput in long term, according to Little’s Law) and Utilisation. Each metric is counted as a running average.
- WIP/LT/TH/UT tab with a diagram – shows how above metrics change in time. You can zoom in the diagram if needed.
- CFD tab with a Cumulative Flow Diagram, showing how, over time, number of tasks in particular stages, change. It’s cumulative, so it’s getting less valuable with time, but you can zoom in and the “done” area will be cut off. You can configure how columns are presented on the diagram by clicking on column names on the right. Checked box starts a new group.
- Scatterplot tab with a diagram showing lead times of tasks in time. No averages, pure events.
- Economics tab with
- Cost of Delay / day – averaged summed CoD of each task in all columns except for the last column.
- Value Delivered / day – averaged sum of CoD of tasks delivered per day.
- Value Dropped / day – averaged sum of CoD of tasks dropped from Backlog columns because of WIP limit.
- WIP – the same as on one of the previous tabs, for comparison.
Notice – Cost of Delay currently is generated randomly for each task using normal distribution with mean 100 and variation 1000.
One more notice – you can change the amount of days for moving averages using the upper right wrench.
Running The Simulation
Hopefully, starting, pausing and stopping the simulation is intuitive. Controls are available in upper left corner:
A pro tip: to speed up the simulation (max speed depends on your machine’s computing power) you can hide the board by clicking on the task area.