Here’s part two of Ian’s series explaining how we work through your requests and issues: Herding Cats – Importance.
When we were a small team back in 2008, and Stephen was out winning new customers or taking project briefs, we used the Eisenhower Urgent/Important Matrix to schedule in work.
By the time we got to 2014, when Mike and I were taking on a lot of the responsibilities, the team had doubled in size and we found that it was difficult to agree on an issue’s status when we were reporting back to Stephen. Often we’d clash, and I’d want to delete an issue as neither urgent nor important, but Mike would be championing the customer’s point of view and arguing it was an urgent and important need. Just like our shameless copying of Google’s urgency descriptions, we borrowed someone else’s ideas for determining importance.
Welcome to Part 2 of 3 posts about how we organise our issues and progress work on MARKUS so that our customers are happy and the product is consistently improving. Part 1 discussed the easy task of categorising and prioritising, this part tackles how we determine how important a task is.
Coffee as a Bad Metaphor
With issue type and urgency we thought we had all the information about each issue we needed in order to be able to schedule it in. A P1 bug obviously trumped everything! But what about a P3 chargeable request that was due to be delivered at a meeting later next week? Too often we found that we were sending Mike to implementation meetings and we had focused on the urgent tasks, and somehow the less urgent but more important tasks had slipped off the radar, and we never found any time to work on underlying problems.
When we tried to balance that the other way we felt like we were ignoring our existing users who had real problems that were preventing them progressing their work – and ultimately we felt that the whole point of EPIX and MARKUS was to provide benefit to our existing customers. Something had to change.
Around the same time we observed that no matter how important or urgent the tasks we were working on were, we still found time to stop and have a chat around the coffee machine. One day we tripped over the fabulous Rocks, Pebbles, Sand analogy (and I don’t mean the 1980 jazz album) which struck a resonant chord. This proved to be a much more powerful solution than just drinking more coffee to solve our planning problems.
Rocks, Pebbles, Sand
Imagine that there’s a hypothetical professor, talking to the new intake of students about prioritising. She takes an empty jar and fills it with rocks, and asks the class if the jar is full. Unanimously they agree, the jar is full. The professor then takes some small pebbles, and fills up all the cracks in the jar. Is the jar full now? The class even more enthusiastically agrees it is NOW full. The professor brings out a bag of sand, and proceeds to fit even more in the jar. The class are now more wary, and whilst the jar seems full, they aren’t so sure. Finally the professor tips her cup of coffee into the jar, and declares it is undeniably full.
The jar is a metaphor for life – with sand representing all the small things: material possessions, chores, TikTok etc. Pebbles represent significant aspects in your life like a home, a job, hobbies. Rocks represent the most important elements – health, relationships.
If you fill your jar with sand, then there is never room for pebbles and rocks – so you should start with what is most important first, there will always be room to fit the less important bits in later. But in the end, there’s always room for a coffee.
We liked the idea so much we adopted it as a basis for prioritising issues straight away!
Backlogs
In Part 1 I discussed our issue tracker, Jira. A big part of how Jira manages work planning is a feature called Backlogs. This is a way to group issues together, and Jira gives us a slick user interface that allows us to quickly shuffle tasks between backlogs, and sequence them up/down within the same backlog. We have three primary backlogs.
Projects (Rocks) – long term strategic items that will have a big impact. We deliberately schedule these tasks to keep MARKUS and the underlying platform improving. The sorts of issues that end up here are cross platform mobile app development, programming stack and language migration issues like the move to PHP8, and technical threats and risks like VAT rule changes. Mike and I also use Rocks to keep on top of the important things for EPIX – like making sure the office is a productive work space, that all the HR and contracts are up to date, and that we are continually finding new talent to join the team.
Product Development (Pebbles) – short term (up to two months) improvements that we choose how we schedule around deadlines and promises. Nearly all issues that are discussed in meetings with customers start off life here, alongside all the paid work including implementations, and interesting new features that would be useful to multiple customers.
Day to day (Sand) – immediate support tasks. This is where all the P1/P2 issues are logged for User Guidance / FOC / bugs requests.
There are two further sneaky backlogs. Broken Windows is our own internal backlog where we can stash User Interface annoyances, coding style problems, and really minor bug fixes that nobody else has noticed. This is where new team members start their coding journey with EPIX, and we also use this backlog to top up the development team if we have small windows of spare time.
The final internal backlog is Everything Else, where issues with no clear sponsor hang out, until something either increases their importance or they are no longer relevant. Mike and I walk through this final backlog on a regular basis to see if we have anything that has been requested by multiple customers, but never chased, or if we have any great product ideas that we’ve all forgotten about. Issues are never closed just because the customer doesn’t remember they asked for it – we only cancel an issue if it is no longer needed, so sometimes a P4 Coding issue might hang out in Everything Else for a couple of years until it either rises back up through the other backlogs, or is cancelled when it is no longer needed.
The September 2024 release included a fix for a broken window that was logged in 2017 – removing an obsolete choice from the communication setup screen. Eventually even the simple and mundane issues will get resolved.
Planning
We have two very distinct planning streams. One set of issues fall into a nice easy planning process because they need to be done straight away. The second set are harder because we have to somehow prevent the first set from getting all the developer time.
The first stream is the Day to Day (Sand) that comes in via phone and email every day – the P1 issues are worked on immediately after they’ve been triaged, and so there is no real planning. The P2 issues are added to the Day to Day (Sand) backlog, and then when all the P1s are done we methodically work through the P2s. This is fun. When a user is talking to Tim about a problem, he is able to answer their questions in real-time, and hopefully when the call is over they will be a happy user able to continue working. If the conversation uncovers a bug, then we can give it to one of the developers straight away to fix, and then get the fix out to the users asap, and everyone is happy.
However, thinking back to our Professor’s hypothetical jar, the rest of the issues are actually more important. We need to hold back the first stream even though they give everyone an instant endorphin hit, and allow enough space in our development jar to work through the rocks and pebbles.
Here are the stats for closed vs open for all the issues raised in a typical month, in this case June 2024.
The final article in this series will look at how we prevent the team from being overwhelmed with sand that never ends so we can work on the P3 and P4 issues. I’ll also reveal the secrets of how we go about deciding when to release fixes and features to customers. I’ll be back soon!
