tl;dr

If you are in a team using operational Atlassian Jira boards with an ‘always empty policy’, try the metric “Total poo count” (= “total customer waiting time in days”) as a forcing function.

Organizing DevOps team work

In many of our client projects, we are employing Atlassian Jira as a tool to shape the flow of work. A typical problem – especially in DevOps teams – is how to balance between development (a.k.a. BUILD) work and operations (a.k.a. RUN) work.

An approach that turned out to prove helpful is a “split board + people-boxing” approach.

Splitting boards

Development work flows at a different time scale than operations work. Typically development work in sprint-style agile methodologies like Scrum flows on the order of magnitude of weeks. During these time boxes of Sprints, focus is preserved and work in progress is protected. Typical ticket types for development work are Epic, Story and Sub-task.

In contrast, operational work flows typically on a day-to-day, hour-to-hour scale. Fast reaction and resolution time matters. Typical ticket types for operational work are Task or Incident.

To accomodate these different natures of work, a split of a team’s work into DEV and OPS makes sense. When using Atlassian Jira or Trello or Microsoft Teams or any other issue tracking solution, this is best reflected by having 1 board for DEV and 1 board for OPS.

Always empty policy

For operational boards, there is no value in maintaining a roadmap or backlog. There is no value in postponing decisions to the last responsible moment. An always empty policy accounts for that and makes it the duty of a team to keep the operational board empty and avoid accumulation of tasks.

People-boxing operations

But how do you balance? How can you maintain the Scrum values commitment and focus while performing excellent operations?

People-boxing your operations is one possibility. In a team of n people, take a defined number of people – say 1 person – and put them exclusively on operations work. The rest of the team works exclusively on development work. That is your people box. Typically this duty is rotating.

In order to properly define the right people box size and to detect emergency situations and react, simple metrics are vital.

Introducing Total poo count

How empty is empty enough? How do you choose a proper people box?

A good metric will reflect customer impact.
A good metric will give the team feedback during day-to-day prioritization.
A good metric is a single number and can be given a target.

It turns out, that this long-sought metric is surprisingly simple: Total poo count is the combined number of days customers are waiting for operational tasks to be resolved. That’s it.

Why is it called total poo count? Read more about the Jira Pile of Poo plugin and the quest to visualize ticket debt.

Measuring Total poo count in Atlassian Jira

Measuring total poo count in Jira is dead simple.

Get all open open tickets in the operational board by JQL, e.g.

project = MY AND issuetype = Task AND status not in (Done, Cancelled)
Limit your output columns to Key, Summary, Created
Export CSV, Comma-Separated
Sum up the number of days since creation with a tool of your choice (Excel, Shell Script, …)

(I personally insert a step in between and curse a lot about stupid choices of date formats. I still don’t get why people in the 21st century use anything else than ISO/RFC.)

Anyways, here is a little bash one-liner to ease your journey in processing the file:

cat My\ Jira\ 2019-08-24T17_07_12+0200.csv | cut -d , -f 4 | tail -n +2 | sed -e 's/\([[:digit:]]\{2\}\)\/\([[:alpha:]]\{3\}\)\/\([[:digit:]]\{2\}\).*/\1-\2-20\3/' | while read d; do echo "$(date --date="${d}" "+%s") $(date "+%s")"; done  | awk '{x += ($2 - $1)/86400;} END {print x;}'

In essence, the steps do:

cut -d , -f 4: select only column #4 = created
tail -n +2: drop the header line
sed -e 's/$[[:digit:]]\{2\}$\/$[[:alpha:]]\{3\}$\/$[[:digit:]]\{2\}$.*/\1-\2-20\3/': convert the date format to sane ISO dates
while read d; do echo "$(date --date="${d}" "+%s") $(date "+%s")"; done: for each line, read the created date and the current date; convert both to seconds since epoch
awk '{x += ($2 - $1)/86400;} END {print x;}: for each line take the difference of now vs. created date, convert to days, sum them up and print the total

Your total poo count will be driven by two factors: Work in progress and cycle time.

Board Smells: High work in progress

For each passing day, a board with 10 open tickets will accumulate 10 piles of poo. A board with 1 open ticket, will only accumulate 1 pile of poo.

A board with too much work in progress will produce high total poo count values. In order to improve your total poo count score, reduce work in progress.

Board Smells: Long-running tickets

Another factor driving total poo count is long-running tickets, resp. high cycle time. In order to improve your total poo count score, make sure customers receive fast resolutions.

Applying total poo count

As with all metrics, the total poo count is useless if it can be ignored easily. Make it part of the daily routine! We prefer to have an exclusive section for operations at the beginning of each daily standup, e.g. a concise prepared newsflash by the person on support including charts (a.k.a. the weather forecast).

Happy clear-out!

Post header background image by falco from Pixabay.

Total Poo Count: The Ultimate Staleness Metric for Operational Jira Boards