Have you ever dealt with time reports? Filled them in? Approved them? Shuffled them around?
Did it feel like well spent time?
Can you imagine a world without time reports?
Here’s the story about how we got rid of time reports at the company described in Scrum and XP from the Trenches.
I wrote the article because I keep bumping into organizations that would benefit from doing the same :o)
4 responses on “How we got rid of time reports”
Great story. I’ve filled timesheets for the last 6 years of my life through 3 different job, and now for the first time I work somewhere where someone had the guts to do what you did and say we we’re going to stop doing them.
I don’t miss them at all. In fact I hadn’t thought about them once until I read this article 🙂
Strangely the rest of our organisation still does them…
Do you have any suggestions about how to eliminate cost account in an organization where the finance team uses cost accounting to capitalize people’s time on projects? For example, some specialist individuals may contribute to 5 different projects in one week.
I note some comments about this in the FAQ in the paper, however, do you have some real-life examples of a finance/accounting team actually agreeing to this? What benefits were put forward to make the case?
*** DISCLAIMER: I am not a financial advisor, and you should check with your Finance folks before implementing anything suggested here. ***
Here is my experience using an Agile substitute for timesheets. At more than one SMB (in Vancouver, Canada), I have used a contemporaneous, traceable association of work tracking. It is enough to satisfy Finance (in particular, tax-credit audits), yet not too much to interfere with Engineers (a primary goal of Agile). Note: These SMBs were producing software product / service, not consulting for clients.
Here are the key parts of this technique:
A. Every sprint (without fail), I (as Lean-Agile lead & impediment remover) create a dedicated wiki page (in Confluence, automatically time-stamped) called the “Sprint Summary”, for each project / product line. Because the sprints are short (2 weeks in our case), this granularity of top-down documentation seems generally acceptable to Finance.
B. The “Sprint Summary” wiki page contains a perma-link to a “Sprint Report” automatically generated by our issue tracker (Jira). This report contains links to all completed issues in that sprint. Each issue automatically contains all of its time-stamped history, in particular, who was assigned (& who peer-programmed) and the status transitions. So Engineers just live in the issue tracker (Jira) like normal: self-assigning issues; working on them; and resolving them. (Product Owner closes them upon “acceptance”.)
C. The “Sprint Summary” wiki page also contains an “Employee Allocation” section, consisting of a table with the following columns: Employee, Role, Sprint FTE. The Sprint FTE is the “full-time equivalent” (number from 0 to 1) of the allocation of that employee in that role to that particular project / product line. I (not the Engineers) fill out this table, which often does not change much sprint to sprint (and wiki pages are easy to clone & tweak). I make it my business to know if someone has been re-allocated to another project or role, in which case I make the appropriate adjustments. At the end of the financial time period (say year), Finance can rollup these FTEs and apply reasonable discounts for things like sick days, company events, etc.
D. Elsewhere, there is a wiki page dedicated to each year for “Days Off”, including everyone’s days off for vacation, appointments, etc., to half-day granularity. Everyone is responsible for reporting their days off on this page. This page also includes all company-observed holidays for the associated year.
Hope this helps!