Tracking time is part and parcel of being a consultant, at least if you have multiple clients and overlapping work. After doing it for 15+ years, I've tried it all - everything from the spreadsheet, to the apps, to forgetting and having to go back and reconstruct.
I read this article and I think it's missing the point about what's so hard about time tracking.
What's hard is: Implementing the trigger on the context switch.
You're working on one thing, something happens and you make a context switch to something else - and in order to track your time, you need a trigger to fire to prompt you to record the switch. It doesn't matter if it's in a spreadsheet or an app or on a piece of paper - I find that my brain doesn't fire that trigger very reliably. Especially if I'm busy.
If someone can solve that problem with a fancy app, I'd be impressed!
I've said it in another thread [1]: I want a robot that watches me and quietly makes intelligent decisions about what I'm really doing, and tracks that.
Sorry, couldn't get past the arrogant know-it-all writing style. "With almost anything in life, there's a right way to do things and a wrong way." Is that so, Socrates? I'd say the opposite, with almost anything in life there are complex and subtle tradeoffs and many good alternatives. Absolute, black-and-white thinking (and writing) is comforting but narrowminded.
"They’ve taken a tool that could give people more ownership over their own work and distorted it into a mechanism for managers to exert control over their team."
This is true for every company, no matter the tool. This could equally apply to a Methodology, meetings, deliverables, timelines, or any other top-down approach designed around coercion.
I'm reminded on Tom DeMarco's thoughts about Control and what kind of projects need such controls [1]:
To understand control’s real role, you need to distinguish between two drastically different kinds of projects:
- Project A will eventually cost about a million dollars and produce value of around $1.1 million.
- Project B will eventually cost about a million dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.
Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.
Caveat though: in a competitive market, all projects will tend to move towards margins of Project A (or worse). When all low-hanging fruits are long gone, and bosses are still trying to optimize some more, tightening control to eliminate variance starts to make sense... for the company.
It seems to me that human values like happiness and respect can only exist where a market isn't efficient yet. It certainly seems so if you look at worker treatment vs. margins/competitiveness.
In Film production control is crucial, because although the returns might be huge, only control allows you to get the best out of a limited budget. Good control means also to know precisely where to leave creative freedoms, otherwise you will end up exactly with a bad version of what was planned.
I recommend activity-watch[0] if anyone wants a good, open-source, at-a-glance system of tracking for their own computer usage. It's definitely helped me rebuild a memory of my activities on days that got away from me.
There is no technical fix that will make managerial time-tracking less of an exercise in control and relentless optimization at the expense of the developer. If you want to preserve some autonomy and dignity, you need to fundamentally restructure the relationship between yourself and management (like with, for instance, a ~union~).
I think this bears some elaboration because I feel the same way, but if we don't talk about _why_ we feel this way, it looks like we're spending our time playing video games and pretending we're working. ("After lunch I just... space out... for a couple of hours. But it looks like I'm working!") I spend a fair amount of time reading documentation; no matter how many programming languages or tools or environments I know, there's always something new to learn. This is true whether I want to learn something new or not - even if I were comfortable just using the stuff I knew when I graduated college, I'll eventually inherit or have to work with something that somebody who knows something newer wrote. As a result, learning new things, reading documentation, experimenting with unknown systems is part of the job - which is completely unappreciated. When I was younger, the managers would ask me what my plan for accomplishing task "X" was and I would start with, "Ok, the first thing I need to do is to learn the environment" and invariably they'd go apeshit when I suggested that I "waste" their time and money on something as pointless as "learning". If I was competent, I'd already know this stuff, and admitting that I needed to waste time reading documentation was sort of an admission of weakness. Of course, being young and naive, I'd try to reason with them but after years and years of having the same circular arguments I finally learned to give bland, inane responses like "research" and avoid giving specifics.
In this case it's a real bummer because it's as if a perfectly fine article was then cut into little pieces, with some of them swapping position. It takes very little to improve it lots, e.g.
> We’re outspoken advocates for tracking time. After all, we are a team of software developers who willingly and knowingly created an application specifically for the purpose of time tracking, right? Our philosophy is simple: time tracking is like fitness tracking, it’s a way for you, as an individual, to assess yourself. We think that it’s totally normal and healthy for developers to want to own their time in a quantifiable way, measure their own abilities, and master their craft.
> But it’s no secret that most developers have a visceral reaction to the very idea of tracking time, and the truth is that most companies do time tracking entirely wrong. The reason why developers hate tracking time so much and fight tooth-and-nail against the idea of having to log hours is because companies have royally screwed it up, they’ve taken a tool that could give people more ownership over their own work and distorted it into a mechanism for managers to exert control over their team. It’s like the company’s way of saying, “Sure, we trust you to do your job… but – just in case – we’re watching you.” What kind of employee-employer relationship do you think that creates?
> With almost anything in life, there’s a right way to do things and a wrong way, and time tracking is absolutely no different. It can be an effective tool for helping developers own and improve their own abilities, but only if management resists the temptations to use it in other ways. In most cases, if the developers on your team hate time tracking, it’s because of how it’s being implemented (or because they have PTSD from a previous job where it was implemented poorly.)
The "How Knowledge Work Happens" graphic is really what resonates with me. I run a dev shop and I hate time tracking for the complexity implied in this image. Questions come to mind.
What counts for time tracking and what doesn't? If I spend an hour emailing back and forth with a stakeholder, none of this is reflected in my GitHub activity. So there is a delta between what is billable time and the actual deliverable.
What if I spend an hour researching a solution for a feature? Or debugging my environment? Again, that implies delta between billable time and the deliverable.
What about my level of expertise? I might be a junior or senior level developer; I might have certain specialized knowledge in an area of programming (or lack it). Again, more delta that tracks closely to the specific logistics of a small feature and less with overall "time".
Suppose I had a machine that strictly tracked the amount of time I spent "doing something project-related" (whatever the specific rubric). At the end of the day, I now have a number. What does this number actually tell me? I am not sure it is that useful and it definitely depends on however the rubric was defined (which would be inherently arbitrary anyway).
To me, it makes sense to just allot hours to devs and trust that they are doing their jobs. When people stop doing their job, peers notice anyway, hour tracking or not.
Time tracking just makes developers better liars. It gives clients the room to be angry, fight contractual obligations, and essentially not pay for the development time.
I just make mine super vague. I put in the number of hours I was in the office, and I summarize most days with some variation on "Made improvements and bug fixes". That's the only way I can spend time doing anything other than actively writing code without stressing out about it.
I used to have that problem but now that I'm freelancing, I actually take care to always have an active clock running on a task I'm working on. It's even improving my focus in a way - I have a constant reminder in my mode line (both in Emacs and in WM) what I'm focusing on.
The key to making this work, when I couldn't make it work in Jira, is lack of friction. In Emacs, if I want to switch tasks I'm working on, it takes the following sequence of keypresses:
C-a a -- switch to Org Agenda
C-s taskn... <ret> -- find new task "taskname" via incremental search
i -- clock in, automatically clocking out the previously active task
s -- save all open org-mode files
q -- close Org Agenda window
It's in my muscle memory, and I can do that faster in there than it takes for a single Jira page to refresh (reason #123 I prefer desktop native over web apps, and don't consider the latter as proper tools).
I'm curious if anyone here has had success with more "coarsely grained" time tracking?
I've found that I'd have no issues tracking my time by day or at most half-day increments, especially since for the most part that's how I end up working on things in a lot of cases (as a developer, not a manager).
I feel like it would give most of the same benefits with a magnitude less work, but I haven't ever tried it out in a real situation before and I'm curious if it holds up.
I've had mixed results with more coarsely grained time tracking. On the one hand I'm more likely to actually do so when I don't have to clock in and out all the time. On the other hand, I kept forgetting to clock in or out because it wasn't 'regular' enough to do it automatically.
These days I use Emacs org-mode for todo items and time tracking (+ pretty much everything else), which makes it much easier to be extremely granular in my tracking without having to expend much effort. Since I have my todo list in front of me for any task anyways, starting the clock is just one keystroke away.
That said, I try to keep myself from calculating how much time I 'need' to save to offset the time it took me to get everything set up and to get comfortable with Emacs/Org-Mode ;).
I've had great success tracking my team, and my team's time, by the day. On the level of "I'm working on project A, project A is now done and I'm now working on project B." It's obviously imperfect but it's good enough to prevent the edge cases, e.g. somebody spending a month on something low priority.
I only care about coarse grained time tracking on my team. I estimate to the quarter day at the smallest, if any task is smaller than that, it shouldn't be a separate WBS item. After all, my end-of-year bean-counter statistics are all based on person days anyways, and I'm not a consultant, so why would I care about tracking to the 15 minute increment?
I was thinking the same thing about 72 hours ago, I mean 3 days ago. In certain fields, like filmmaking, freelancers don't charge by the hour. They have a day rate. You pay them for the whole day or not at all. Some let you hire them for half a day.
I got into the habit of keeping a daily work log, and continue to do so even though I no longer work for a company that requires it. Very simple: Date, number of hours (0.5 granularity), planned work, actual work done, links to work output or meeting notes (if any). That’s it. It helps me to get back up to speed after a weekend. It allows me to tell you what happened on that day X months ago when we were in the middle of project Y without searching my email for clues. It is very helpful for yearly performance reviews, allowing me to provide a detailed accounting of everything, big and small, that I did since last year. The self-assessment pretty much writes itself.
I keep a hledger timedot file[1] open in a hot-key drop-down iTerm window. Each 15-minute chunk is logged with a dot. I group dots into hours for quick visual scanning.
I've trained myself to update this often while at the computer, and before walking away. Delayed retroactive logging is also pretty easy. Working in quarter/half/whole hour chunks, and in rhythm with the clock, and having a pane showing recent sleep/wake/timelog-saved events, all help. Not every day is the same; this system has been quick and flexible enough to suit a range of conditions. I can set daily/weekly/monthly time budgets if I want. Some more details at [2].
Time tracking and continuous code code review is an important way to spot workers who can't stay on task or are way over their head. If you can catch issues early, you can help them and the team succeed. If you lack time tracking and continuous code review many developers will "fall through the cracks" and it will take much longer to discover they are a net negative to the team. Even if it becomes apparent, it becomes much easier to point to sometime somewhat objective then gut feelings.
Time tracking is good for accountability. Time tracking should be simple. Time tracking should only loosely be associated with tasks.
* Email 0:45
* Meet with customer 1:00
* Program Complete solution and deploy it (TASK045) 0:05
I would be very wary of developers who refuse to accurately track their time.
Tracking at the microlevel is horrible. The time wasted keeping up and the padding in explainable areas to offset the undocumented task like pick up phone, talk to coworker, get water, go to bathroom, answer question.
In your example email took 15 minutes in reality it took 1 minute and I've used 14 minutes to get a coffee speak to an employee about upcoming company bake sale, holding the door for the CEO and getting to the conference room 5 minutes early to meet the client.
Nothing beats that time our company had us filling out 3 different time tracking systems at the same time and complaining that some of us were adding time tracking as a task that required time tracking.
Back in school, I worked part-time for a group that used limited time tracking; you input when you worked and how many hours per project, but didn't have to match hours to tasks. The one minor flaw in this program was that it didn't let you pick your hours worked - it simply asked for a single start and end time each day. Working two hours in the morning and two in the afternoon was impossible to input.
Blessedly, it was an internal tool rather than a way to track client billing; the standing instructions were to just choose some random block of hours corresponding to your total time worked, so that you could get to the project-hours fields that actually mattered. But internal usage also raised the question of why they were voluntarily keeping a tool slightly less effective than a century-old punchclock.
Reminds me of the SAP software a previous employer used.
One of my reports worked 4 days a week ... so if they took a half day of leave at any point come the end of the year they would typically have 0.499. or 0.999. left to take.
> It’s like the company’s way of saying, “Sure, we trust you to do your job….but–just in case–we’re watching you.”
This feels hyperbolic. There are legitimate reasons to measure time spent, and it doesn't amount to lack of trust. And similarly, failure to meet time expectations doesn't amount to shirking or lying.
That said, I personally think it's wise to track your own time for a variety of reasons, one of which is to have some defense against someone else's measurements.
I worked at a game studio where the employees were on average reporting 60+ hours of work. The managers wanted to verify the survey data, so they implemented opaque time tracking (meaning they didn't show the employees the data, and they anonymized the data and didn't use it to come down on individuals, only to collect aggregate information.)
The result was that employees were factoring their commutes as well as optimistic expected arrival and departure times, and fairly dramatically over-estimating how much they actually worked. The average was much closer to 40, and 25% of the company was working less than 40 during final production crunch. I personally tracked my own time at the same time, and it turns out I was also working less than I thought. There's no doubt that crunch feels like more work, but measuring revealed a discrepancy between feelings and reality.
I didn't realize that most were working 9-5 or some variation or less in the game industry. Do you find on most days you usually work 8 hours and leave. You work an hour extra one day but leave an hour earlier on friday?
I quit 3 jobs in the last 5 years and time tracking by management is high up on the reason list. I will now refuse to work for any organisation that does it.
The code and design quality turns to shit in such places. Everyone is trying to keep to the beat of their allotted time. Here’s your shovel. Dig a tonne of soil. You have 2 hours. No one is thinking of hiring a JCB because well thinking about that takes time from your time tracked task.
Places that don’t track time probably get better results although they can’t prove it with metrics. Compare it to parenting, why aren’t we timing nappy/diaper changes? Oh because it’s mostly instinctive. A bit like programming!
Sure we need to make sure we are on track but this can be done at much a higher level. Story points used properly fill this goal. Where I work we use them but there is no punishment for not meeting the story points. Not even a frown of disappointment that when we added up some numbers from a random distribution, they didn’t add up to some arbitrary number. Story points are a useful indicator, but they are part of a vector of information. We didn’t meet the story points because we worked on some technical debt, because ... for example.
So in conclusion don’t you dare track my time and pull me in a room because I didn’t dig that hole quick enough.
[+] [-] bm98|7 years ago|reply
I read this article and I think it's missing the point about what's so hard about time tracking.
What's hard is: Implementing the trigger on the context switch.
You're working on one thing, something happens and you make a context switch to something else - and in order to track your time, you need a trigger to fire to prompt you to record the switch. It doesn't matter if it's in a spreadsheet or an app or on a piece of paper - I find that my brain doesn't fire that trigger very reliably. Especially if I'm busy.
If someone can solve that problem with a fancy app, I'd be impressed!
I've said it in another thread [1]: I want a robot that watches me and quietly makes intelligent decisions about what I'm really doing, and tracks that.
[1] https://news.ycombinator.com/item?id=15790918
[+] [-] QuadrupleA|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] JamesLeonis|7 years ago|reply
"They’ve taken a tool that could give people more ownership over their own work and distorted it into a mechanism for managers to exert control over their team."
This is true for every company, no matter the tool. This could equally apply to a Methodology, meetings, deliverables, timelines, or any other top-down approach designed around coercion.
I'm reminded on Tom DeMarco's thoughts about Control and what kind of projects need such controls [1]:
To understand control’s real role, you need to distinguish between two drastically different kinds of projects:
- Project A will eventually cost about a million dollars and produce value of around $1.1 million.
- Project B will eventually cost about a million dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.
Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.
[1]: https://www.computer.org/cms/Computer.org/ComputingNow/homep...
[+] [-] TeMPOraL|7 years ago|reply
It seems to me that human values like happiness and respect can only exist where a market isn't efficient yet. It certainly seems so if you look at worker treatment vs. margins/competitiveness.
[+] [-] atoav|7 years ago|reply
[+] [-] jacobtwotwo|7 years ago|reply
[0] https://github.com/ActivityWatch/activitywatch
[+] [-] whyisthewhat|7 years ago|reply
[+] [-] commandlinefan|7 years ago|reply
[+] [-] sagichmal|7 years ago|reply
[+] [-] PavlovsCat|7 years ago|reply
> We’re outspoken advocates for tracking time. After all, we are a team of software developers who willingly and knowingly created an application specifically for the purpose of time tracking, right? Our philosophy is simple: time tracking is like fitness tracking, it’s a way for you, as an individual, to assess yourself. We think that it’s totally normal and healthy for developers to want to own their time in a quantifiable way, measure their own abilities, and master their craft.
> But it’s no secret that most developers have a visceral reaction to the very idea of tracking time, and the truth is that most companies do time tracking entirely wrong. The reason why developers hate tracking time so much and fight tooth-and-nail against the idea of having to log hours is because companies have royally screwed it up, they’ve taken a tool that could give people more ownership over their own work and distorted it into a mechanism for managers to exert control over their team. It’s like the company’s way of saying, “Sure, we trust you to do your job… but – just in case – we’re watching you.” What kind of employee-employer relationship do you think that creates?
> With almost anything in life, there’s a right way to do things and a wrong way, and time tracking is absolutely no different. It can be an effective tool for helping developers own and improve their own abilities, but only if management resists the temptations to use it in other ways. In most cases, if the developers on your team hate time tracking, it’s because of how it’s being implemented (or because they have PTSD from a previous job where it was implemented poorly.)
[+] [-] jopsen|7 years ago|reply
* I only have time for bullet points :)
[+] [-] theandrewbailey|7 years ago|reply
[+] [-] rhizome|7 years ago|reply
[+] [-] devilshaircut|7 years ago|reply
What counts for time tracking and what doesn't? If I spend an hour emailing back and forth with a stakeholder, none of this is reflected in my GitHub activity. So there is a delta between what is billable time and the actual deliverable.
What if I spend an hour researching a solution for a feature? Or debugging my environment? Again, that implies delta between billable time and the deliverable.
What about my level of expertise? I might be a junior or senior level developer; I might have certain specialized knowledge in an area of programming (or lack it). Again, more delta that tracks closely to the specific logistics of a small feature and less with overall "time".
Suppose I had a machine that strictly tracked the amount of time I spent "doing something project-related" (whatever the specific rubric). At the end of the day, I now have a number. What does this number actually tell me? I am not sure it is that useful and it definitely depends on however the rubric was defined (which would be inherently arbitrary anyway).
To me, it makes sense to just allot hours to devs and trust that they are doing their jobs. When people stop doing their job, peers notice anyway, hour tracking or not.
[+] [-] AtlasBarfed|7 years ago|reply
[+] [-] teddyh|7 years ago|reply
[+] [-] tomphoolery|7 years ago|reply
[+] [-] _bxg1|7 years ago|reply
[+] [-] welder|7 years ago|reply
It shows when you started and stopped working for the day.
An example chart: https://wakatime.com/blog/27-fill-the-gaps-in-your-coding-ac...
[+] [-] ams6110|7 years ago|reply
I've done this with good success when I was required to track my time. If I'm not required to do it, I find that I just dont bother.
[+] [-] TeMPOraL|7 years ago|reply
The key to making this work, when I couldn't make it work in Jira, is lack of friction. In Emacs, if I want to switch tasks I'm working on, it takes the following sequence of keypresses:
It's in my muscle memory, and I can do that faster in there than it takes for a single Jira page to refresh (reason #123 I prefer desktop native over web apps, and don't consider the latter as proper tools).[+] [-] arethuza|7 years ago|reply
[+] [-] Klathmon|7 years ago|reply
I've found that I'd have no issues tracking my time by day or at most half-day increments, especially since for the most part that's how I end up working on things in a lot of cases (as a developer, not a manager).
I feel like it would give most of the same benefits with a magnitude less work, but I haven't ever tried it out in a real situation before and I'm curious if it holds up.
[+] [-] mercer|7 years ago|reply
These days I use Emacs org-mode for todo items and time tracking (+ pretty much everything else), which makes it much easier to be extremely granular in my tracking without having to expend much effort. Since I have my todo list in front of me for any task anyways, starting the clock is just one keystroke away.
That said, I try to keep myself from calculating how much time I 'need' to save to offset the time it took me to get everything set up and to get comfortable with Emacs/Org-Mode ;).
[+] [-] SatvikBeri|7 years ago|reply
[+] [-] anumberofopt|7 years ago|reply
[+] [-] combatentropy|7 years ago|reply
[+] [-] ryandrake|7 years ago|reply
[+] [-] smichael|7 years ago|reply
[1] http://hledger.org/timedot.html
[2] http://hledger.org/Time-planning.html#simons-hledger-time-da...
[+] [-] kardianos|7 years ago|reply
Time tracking and continuous code code review is an important way to spot workers who can't stay on task or are way over their head. If you can catch issues early, you can help them and the team succeed. If you lack time tracking and continuous code review many developers will "fall through the cracks" and it will take much longer to discover they are a net negative to the team. Even if it becomes apparent, it becomes much easier to point to sometime somewhat objective then gut feelings.
Time tracking is good for accountability. Time tracking should be simple. Time tracking should only loosely be associated with tasks.
* Email 0:45 * Meet with customer 1:00 * Program Complete solution and deploy it (TASK045) 0:05
I would be very wary of developers who refuse to accurately track their time.
[+] [-] wolco|7 years ago|reply
In your example email took 15 minutes in reality it took 1 minute and I've used 14 minutes to get a coffee speak to an employee about upcoming company bake sale, holding the door for the CEO and getting to the conference room 5 minutes early to meet the client.
[+] [-] Sylamore|7 years ago|reply
[+] [-] throwmeback|7 years ago|reply
[+] [-] jSully24|7 years ago|reply
[+] [-] hathawsh|7 years ago|reply
[+] [-] stesch|7 years ago|reply
Hmm. As a software developer you get really frustrated when you have to deal with this expensive piece of software.
[+] [-] Bartweiss|7 years ago|reply
Blessedly, it was an internal tool rather than a way to track client billing; the standing instructions were to just choose some random block of hours corresponding to your total time worked, so that you could get to the project-hours fields that actually mattered. But internal usage also raised the question of why they were voluntarily keeping a tool slightly less effective than a century-old punchclock.
[+] [-] philjohn|7 years ago|reply
One of my reports worked 4 days a week ... so if they took a half day of leave at any point come the end of the year they would typically have 0.499. or 0.999. left to take.
[+] [-] jgust|7 years ago|reply
>if we don't report whole number cap-ex hours on our return, we'll avoid an audit!
[+] [-] dnautics|7 years ago|reply
[+] [-] dahart|7 years ago|reply
This feels hyperbolic. There are legitimate reasons to measure time spent, and it doesn't amount to lack of trust. And similarly, failure to meet time expectations doesn't amount to shirking or lying.
That said, I personally think it's wise to track your own time for a variety of reasons, one of which is to have some defense against someone else's measurements.
I worked at a game studio where the employees were on average reporting 60+ hours of work. The managers wanted to verify the survey data, so they implemented opaque time tracking (meaning they didn't show the employees the data, and they anonymized the data and didn't use it to come down on individuals, only to collect aggregate information.)
The result was that employees were factoring their commutes as well as optimistic expected arrival and departure times, and fairly dramatically over-estimating how much they actually worked. The average was much closer to 40, and 25% of the company was working less than 40 during final production crunch. I personally tracked my own time at the same time, and it turns out I was also working less than I thought. There's no doubt that crunch feels like more work, but measuring revealed a discrepancy between feelings and reality.
[+] [-] wolco|7 years ago|reply
[+] [-] quickthrower2|7 years ago|reply
The code and design quality turns to shit in such places. Everyone is trying to keep to the beat of their allotted time. Here’s your shovel. Dig a tonne of soil. You have 2 hours. No one is thinking of hiring a JCB because well thinking about that takes time from your time tracked task.
Places that don’t track time probably get better results although they can’t prove it with metrics. Compare it to parenting, why aren’t we timing nappy/diaper changes? Oh because it’s mostly instinctive. A bit like programming!
Sure we need to make sure we are on track but this can be done at much a higher level. Story points used properly fill this goal. Where I work we use them but there is no punishment for not meeting the story points. Not even a frown of disappointment that when we added up some numbers from a random distribution, they didn’t add up to some arbitrary number. Story points are a useful indicator, but they are part of a vector of information. We didn’t meet the story points because we worked on some technical debt, because ... for example.
So in conclusion don’t you dare track my time and pull me in a room because I didn’t dig that hole quick enough.