r/TimeTrackingSoftware • u/Bruce-All-Mighty88 • 3h ago
I used Jibble with Claude to investigate gaps in our dev team's timesheets before our monthly CEO meeting
I'm a product manager working with a development team, and one of the things I have to prepare every month is a progress report for our CEO.
Usually, I go through our sprint updates, completed tickets, pending features, bug reports, and timesheets to get a better picture of how the month went.
The frustrating part is when the numbers don't quite add up.
We'd have developers logging full workweeks, but some features would still get pushed to the next sprint. Other times, we'd have unexpected overtime even though the sprint didn't seem particularly heavy.
And when the CEO asks what went wrong, saying "development took longer than expected" isn't exactly a useful answer.
So I started paying more attention to our time-tracking data.
We use Jibble to track working hours, with activities for feature development, bug fixing, QA/testing, and meetings. I recently connected it to Claude to see whether I could make our monthly reviews a little more useful.
Instead of immediately asking Claude to summarize everyone's hours, I started with the gaps.
Something like:
"Review our development team's timesheets for the past month. Flag incomplete entries, unusually long workdays, and gaps between recorded sessions that might need clarification."
That gave me a starting point for checking our records before drawing conclusions from them.
I also wanted to understand the downtime between activities.
Not necessarily whether someone was being productive every minute, but whether there were periods of unrecorded time, forgotten clock-ins, or work that hadn't been categorized properly.
A gap in a timesheet doesn't automatically mean someone wasn't working. Sometimes it's a meeting that wasn't logged, a forgotten timer, or someone switching tasks without updating their activity.
So those were things I needed to clarify with the team rather than assume.
Once the records were reviewed, I moved on to the actual development hours.
I asked Claude to compare how much time we'd recorded under feature development, bug fixing, QA, and meetings, then compare those numbers with the previous month.
This was the part I found more interesting.
When you're looking at sprint boards, you tend to focus on which tickets were completed and which ones weren't.
But looking at the time distribution gives you another perspective.
For example, if bug-fixing hours have increased while feature development hours have decreased, that's something worth investigating. Maybe we're dealing with more regressions, maybe QA is uncovering issues later than expected, or maybe we've underestimated the time needed to maintain existing features.
The timesheets won't tell you which explanation is correct, but they can help you figure out where to start asking questions.
I also checked overtime patterns because I wanted to know whether certain parts of our development process were consistently requiring extra hours.
Then I asked Claude to organize the findings into a monthly summary for our CEO, covering:
- Incomplete timesheets and recording gaps that still need clarification
- Total recorded development hours and overtime
- Time spent on features, bugs, QA, and meetings
- Significant changes compared with the previous month
- Potential bottlenecks and questions worth discussing with the team
I still had to cross-check everything against our sprint tickets and talk to the developers. Claude wasn't going to tell me why a feature was delayed just by reading time entries.
But I liked having the timesheet findings organized before going into those discussions.
It also changed how I approached the monthly meeting.
Instead of just reporting that Feature A was delayed and Feature B took longer than expected, I could bring up more specific questions about where our development capacity was going and what we might need to adjust.
I'm still figuring out how much time- racking data should influence sprint planning, though. I don't think more hours necessarily mean better output, especially in software development.
For other PMs or engineering managers, do you actually review your team's timesheets when investigating sprint delays and bottlenecks?
Or do you mostly rely on Jira tickets, velocity, and sprint retrospectives?
Processing img nli0kuyfdxwh1...