Kanban distributed responsibility
With 2018 completed, I wanted to take a look at how the statistics for epics for last year worked out. Are we able to deliver continuous improvements on time, and does our framework live up to its promises? Here are some of the detailed insights:
We had 42 epic owners in 2018 (80% of our current staff count), fulfilling our promise that taking ownership of a project is something everybody will get the opportunity to do. To recap: Epics are sprint-sized projects in our Kanban flow, involving multiple teams, with one person planning and driving each. The person owning the most epics was Nicole with 20.
The average estimated time for an epic was 8.4 working days, while the average completion time was 12 working days. In total 99 epics were finished on time (40%), 40 of them ahead of time. The accuracy of estimations have improved in the second half of the year, and we will aim for the number of epics on time in 2019 being in the triple digits :) On average, we are close to typical 2-week sprints, but the variability is great:
The winner of the shortest epic goes to Alex G. He had not 1, but 2 epics which were finished on the same day they were started, both hotfixes. Hotfixes are special epics created from a template, to make sure we cover all the steps. Just as other epics, they have an owner who is responsible for communication, making sure everything works out smoothly and achieving the goal of ridding production servers of the issue.
The longest epic was 37 days, of which the dubious honor goes to Calin (with the narrowest of margins). This was done when we were still learning how to work with our framework, very long epics like this did not happen in the second half of 2018.
The fastest epic compared to the estimate was done by Gabriel, who in 7 days finished an epic with a 16 day estimate.
In 2018 we finished 254 epics. Given 250 working days in Norway, that is equivalent to one epic every day. We finished epics every single week of the year, thanks to Paulo who was at work between Christmas and New year and got his geo work finished.
The bug fixing epics in the portal were the epics with the most people involved, June being the winner with 24 contributors. This was also the epic with the most tasks, 160 in total. As above with long epics, this number is something we have since been able to reduce, December had 57 tasks.
The epics with the highest number of JIRA projects were “Shut down old servers” with 9 projects across 8 teams (Infrastructure, Munin, Backend, Loki, QA, Freki, Email alerts and Test Automation), and “Backend geo blockers”, also with 8 teams (Backend, Freki, Munin, Loki, System Tools, Email alerts, Mohawk and QA). Some of these “teams” are one-man teams, with a special area of responsibility.
The team involved in the most epics was, by a wide margin, QA, which was involved in 156 epics.
The average number of tasks per epic was 17, while the average number of projects was 2.7. This number is important; to achieve gradual improvements, every epic should deliver something of value to end users. With 2–3 teams working together on every epic, it shows we are able to cooperate in practice, which is a requirement for this.
Based on experience from 2018, we are able to make the framework work for us. We have been able to avoid too large/long epics in the fall, and estimation accuracy is OK, but may still be improved. Size-wise, the teams seem to have found a sweet spot in terms of average length, size and involvement. Some of our main focus areas for 2019 are not covered in these statistics. We want to ensure epics can deliver value (rather than enabling value to be delivered in a later epic), to make sure all code has at least two people familiar with it, and better combine short epics with longer term goals.
