Published at July 5, 2019 · 4 min read · by MyHammer
Our engineering teams use a technical backlog to maintain a list of all technical debts and technical improvements. Each team member can add a new task, Story, or Epic into the backlog. Bugs or technical issues that are related to the business logic are not considered in this backlog but prioritized into the product backlog. Our Tech leads gather once a week to discuss the newly added items and to prioritize the technical backlog. Items get removed or rejected if the actual problem does not exist anymore or if another ticket addresses the problem.
To decrease the number of tasks in the backlog our scrum teams have a reserved time, during each one week sprint they can work on technical tasks this is mostly 20% of the sprint time, engineers can organize themselves to work on the tasks. Reserving this time during every sprint allows us to continuously decrease the number of technical tasks and keep our technical debts low.
Often we do not have enough time during the sprint to focus on the technical tasks because we have to focus on the sprint goals. The technical tasks have mostly lower priorities than product related tasks. Furthermore, engineers often do not find enough time to finish a task which means that they have to get back to the task in another sprint or worse the tasks get deprioritized and stay in the backlog until someone else works on it which is of course not very productive.
Another problem we often face is that specific tasks need not only one engineer but involve different persons from different teams, this causes a strong dependency since our teams work in autonomous cross-functional teams and other team members might not be available at the same needed.
Based on the problems we were facing, we made a list of requirements that are important to us:
- we need to be able to focus more on the task
- we want to be able to work focused for a more extended period on the same task
- we need to be able to involve any expert needed from any team
One of our ideas was to have a dedicated day once a month that is not a sprint day and during which every team can collaborate with everyone, we decided to implement this and give it a name: TechDay. Since we do not want to increase the total amount of time spend on the tech backlog, we will in the same time reduce the time dedicated to the tech tasks during a sprint to 10% from the current 20%
Changes: 10% of sprint time dedicated to the tech backlog + 1 full day per month dedicated to the tech backlog
During a TechDay, there is no meeting or sprint related work. Furthermore, the teams are protected from any outside request like it is during a typical sprint. The engineers only accept critical issues that affect the business so-called priority 1 bugs this is the same process as during a regular sprint, product owners are in charge of business-related bugs, and the on-call team handles all technical related impact.
Like with any other improvement we want to make we start with an experiment to minimize the risk and to measure the success or failure of the change.
To run an experiment, we define the following things:
- how long we want to run it
- how we can measure if it is successful or not
- who is involved
- what do we need to prepare
How long we want to run it ?
Since a TechDay occurs once a month and we want to have a few iterations to compare we have decided to run the experiment for 6 Months with an internal retrospective after every TechDay to adapt the process if needed or worst stop the experiment.
How can we measure if it is successful or not ?
The main problem we want to solve with the TechDays is to give more focus and facilitate cross-team exchange, which both helps us to finish tasks faster in our tech backlog and therefore decrease the technical debts.
At MyHammer, we are using Jira as a ticketing system which gives us enough data to compare the resolution time based on the complexity of the tasks over a more extended period. By comparing the resolution time before the experiment and after the experiment, we can see if we can resolve the technical tasks faster than without the Techdays.
Additionally, to the resolution measurement, we also gather feedback data from our engineering and product teams to evaluate the level of satisfaction with the process and identify the pain points.
Who is involved ?
We involve all our engineering and product teams. Engineers can work focused on the tech backlog without being disturbed by meetings or sprint related work and the product team can dedicate their time to work on product related tasks such as research, preparing stories for upcoming sprints and stakeholder management.