Issue Tracking Anti-Patterns: Logging Work Hours (and Solutions)
A common mistake recurring in software teams is logging work hours in tickets, even worse, using them to make estimations.
Usually the intention is to measure who spends how much time while solving a particular ticket. In such cases, engineers are expected to log their effort every time they do some work on a ticket.
This is neither correct, nor good way of measuring efforts. (Unless you log it for the billing purposes, but that is still not related to software development improvements)
Ticket systems already track most important timestamps for issues. Some of them can be mapped to well known concepts, namely Lead Time and Cycle Time. Correct interpretation of those helps you to notice problems in your flow, just like they help countless manufacturing companies for decades.
Lead Time
Lead Time starts when your ticket is created and stops when you reach the border of your responsibility. If your responsibility includes the deployment, then lead time stops when your changes are actually deployed.
Lead Time is an important indicator to measure your delivery performance from end-to-end view. Lead Time is what your customer cares. For the customer, the only important point is how fast they get solutions without compromising the agreed quality and price.
Cycle Time
Cycle Time starts when actual work on the ticket starts. Typically, this happens when the production actually begins. This is more flexible in software. Some consider the moment when implemention begins as the beginning of the cycle time. Others can start this timer by requirement gathering. (I would do similar as well since requirement gathering can be seriously time consuming part of a story which directly impacts the outcome)
Therefore, how much time you spend on a ticket is actually automatically tracked when you change the state of your ticket properly.
Obviously, you will want to know how much time a ticket stayed in every state. That is why you should configure your ticket flow in a way that it maps to the reality.
For example, if your ticket states include only Open, In Progress, Resolved, Signed Off while you do regular activities like prioritization sessions, pokers, testing (there are situtations where fully automated tests are not possible), security analysis etc, you need to have those in your flow as well.
Proponents of work logging always have the same argument here:
Even though I move ticket to in-progress, I do not spend all my time on it. Sometimes I do other tasks, or sometimes I am blocked by something else and that is why I need work logging
Limiting WIP
When you produce above argument, you actually have a hidden problem and you are looking at the wrong direction to solve it.
If you are working on multiple tickets at the same time, you are dangerously moving around one of the known productivity killers. Limiting work in progress is essential to keep cycle times low.
Benefits of limiting the work in progress is not only for the whole team, but it also applies to individuals.
More than 5 decades ago, Prof. John Little came up with Little’s Law that says:
The long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system
This law has found wide acceptance and usage in production planning. Taiichi Ohno, the founder of the Toyota Production System, also defines cycle time in a similar way:
cycle time is computed by dividing operating hours by the quantity required per day
In software, and typically in Kanban, this translates like:
Lead Time = WIP / Throughput
where throughput is the rate of issue resolution, or your efficiency.
Provided that your efficiency is same, you need to decrease WIP in order to reach lower lead times which means delivering solutions faster.
Or, you can increase your efficiency by eliminating wastes in your process, automating manual tasks etc while keeping WIP same, in order to decrease lead time.
However, you should avoid switching tasks unless it is absolutely necessary.
You should focus on finishing items, rather than starting them
Still, getting blocked for a long time while working on a ticket happens. In most organizations, you will see that engineers just keep pulling in more tickets (or even worse, start working on things that isn’t recorded anywhere), without actually escalating the blocked tickets. Tickets will look like they are in progress, but nobody will know the reality. The ticket will start lying about itself.
Lies ? What lies ?
If people have to read comments to find out blocked tickets, you are lying in the ticket status. It says “in-progress” but it is not progressing at all.
This is the place you need to intervene.
If your ticket is unable to progress anymore due to conditions out of the assignee’s hands, you need to have states or labels (whichever is more suitable in your issue tracking system) that will visualize this situation when you look at your board. The key is to make real state of each ticket visible at first sight.
I will not get in to detail, as every organization is different. If you find yourself usually blocked by same entity (eg: IT, procurement etc) you can create a visualizer for that. If there is no common pattern in the source of block, a generic visualization may also work.
See the following, extremely simplified Trello board for example. Which ones are actually being worked on and which ones are blocked:
Bad Board
Impossible to tell, right ? Now check this one:
Good Board
It turns out that, 4 ticket is blocked. Even such a small touch can give critical information. Now it is time to find out what prevents the progress and is it possible to eliminate or at least decrease the time wasted on them.
Coming back to real cases, how will you see where you waste your time and hurt your development in shortest amount of time, if you have hundreds of tickets ?
Important points here:
- Configure your flow so that it reflects the reality
- Visualize when tickets are blocked, make problems visible
- Prefer using features that will also automatically track the time spent while blocked (issue states usually better for this)
- If possible, let engineers change the state of a ticket via check-in messages so that they don’t have to remember editing tickets exclusively.
If you are considering adopting Lean Software Development principles, visualizing blockers -when team members act responsibly to mark- can act as low hanging fruits for eliminating waste in your flow.
After a while, you will notice patterns in those.
How About Urgencies ?
Shit happens, urgent tickets arrive. What makes a ticket urgent is the SLA bound to it. If the SLA tells that you have to finish it in 15 minutes, you have to finish it in 15 minutes.
Important point here is, tickets can not be arbitrarily urgent. You need to have clear definitions on what conditions make a ticket more important than others. You need to have SLA written down.
It does not have to be rational (but it would be better that way). If your CEO wants his/her tickets to be handled immediately, make this an SLA and stick with it.
This will allow you to collect statistics on how your CEO’s approach actually affects your production. Visualizing and backing it with data is better than silently ignoring or complaining without data.
Most teams make the mistake of ignoring the guidelines, rules they wrote.
Do not put a rule if you are going to ignore it later
Ignoring your own rules poisons your culture, erodes the trust. If your rules have flaws, those will be visible by looking at your data, provided that your issue tracking system is honest. When the rules don’t meet your business needs, immediately improve them.
Studying Cycle Time
If you have good issue tracking system (or Excel skills), you can look your performance from very different views.
Cycle time can be calculated for whole team and it will give complete top level statistic.
What else is possible ?
For example, you can calculate the cycle time for medium sized REST API stories. Or, you can calculate it for small sized UI stories. (i.e component based) If you get standard deviations, you will be able to tell best/worst case expectations, based on real data.
Therefore, interpeting the data lying in your issue tracking system can give great insight about your capabilities in different areas, which will open the way towards making more accurate, data driven estimations.
People who don’t know how to use such data usually end up making estimations based on personal experience (i.e: gut feeling)
This ability becomes more important as you have more ticket to finish, more customers to satisfy and more complex roadmap to complete. It will also let you build trust between you and your stakeholders regarding to execution of your roadmap execution.
Conclusion
Whatever we do with an issue tracking system, we essentially do it in order to improve our work and become more efficient.
If we hold on to continous improvement principles through data driven decisions, reorganizing the issue tracking system, focusing on Lead-Cycle times and limiting WIP will work much better than asking everybody to write how many minutes/hours they think they spent on a certain task.
Is bugging engineers to log their work really going to tell you the crucial information that will help you improve your efficiency ?
Or should you better focus on visualizing your real flow and studying the data hidden in your issue tracking system in order to apply more scientific methods ?
Note
Some may wonder why I wandered around concepts like realistic visualization of your flow, cycle time, WIP which usually go along under the umbrella of Kanban, without calling it explicitly. (Even though I am biased towards Kanban)
As I mentioned in here, many organizations make the mistake of craving for magical quick recipes to follow blindly. (And blame them as scape goat when they fail) You may find yourself actually running Kanban while implementing such concepts. But that is not the only path you can end up with.
Kanban is a way of visualizing and managing the work flow. It is a tool, which may or may not work for you. There are different tools and endless possibilities for adaptation.
I consider following higher level ideals like continuous improvement and lean development principles more important than immediately jumping in to tools. Those principles are more goal oriented. Following them properly will anyway force you to implement some sort of work management system, in order to be able to assess and tune your performance.