Time tracking for building software

[Greg Robinson]

Companies that want to capitalize their expenses for building software need
their development teams to track time they spend on building and testing
software. Has anyone heard of a company requiring their teams to track the
time they spend as part of the tasks in the Agile Project Management Tool
being used?

For example, if a user story consists of 5 tasks and task1 was estimated at
6hours but it only took 3 hours to complete, than the developer is required
to enter the actual effort of 3 hours into the tool for time tracking
purposes.

I can understand tracking the estimated vs actuals over the course of a
sprint or two in order to help improve team agility and estimation
practices, but I've never heard of it being mandated as a time entry
system. This can be a problem particularly for mature teams that don't use
tasks or task hours.

What have you seen work? What downsides do you see to this?

Looking for comments or thoughts.

Thanks.
Greg

[Nayan Hajratwala]

Companies that want to capitalize their expenses for building software need their development teams to track time they spend on building and testing software. Has anyone heard of a company requiring their teams to track the time they spend as part of the tasks in the Agile Project Management Tool being used?
For example, if a user story consists of 5 tasks and task1 was estimated at 6hours but it only took 3 hours to complete, than the developer is required to enter the actual effort of 3 hours into the tool for time tracking purposes.

If you have 5 people working on a team in 1 weeks sprints, and they complete 3 features during that week, then the 3 features took a total of 5 * 40 = 200 hours to complete.

Does capitalizing require that you say "feature 1 took 100 hours, feature 2 took 60 hours, and feature 3 took 40 hours”?

---
Nayan Hajratwala - 734.658.6032 - http://agileshrugged.com - @nhajratw

[Ron Jeffries]

Greg,

Post by Greg Robinson
What have you seen work? What downsides do you see to this?

For years, I was VP R&D for an organization that capitalized software development (a very bad idea IMO, but OT for here).

With dedicated teams, pretty much everything the team does goes to that project. With non-dedicated teams (avoid like the plague, as they reflect poor management and distracted work and delayed value for everyone), apply percentages.

No one knows better, and no one really cares.

Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?
-- Ronald Reagan

[Adam Sroka]

Figure out what you need to charge for a weeks worth of work to make margin
and charge that. The number will likely be lower if you don't waste
talented peoples' time making them poke phony numbers into some tracking
software.

Post by Greg Robinson
Companies that want to capitalize their expenses for building software
need their development teams to track time they spend on building and
testing software. Has anyone heard of a company requiring their teams to
track the time they spend as part of the tasks in the Agile Project
Management Tool being used?
For example, if a user story consists of 5 tasks and task1 was estimated
at 6hours but it only took 3 hours to complete, than the developer is
required to enter the actual effort of 3 hours into the tool for time
tracking purposes.
I can understand tracking the estimated vs actuals over the course of a
sprint or two in order to help improve team agility and estimation
practices, but I've never heard of it being mandated as a time entry
system. This can be a problem particularly for mature teams that don't use
tasks or task hours.
What have you seen work? What downsides do you see to this?
Looking for comments or thoughts.
Thanks.
Greg

[George Dinwiddie]

Greg,

Post by Greg Robinson
Companies that want to capitalize their expenses for building software
need their development teams to track time they spend on building and
testing software. Has anyone heard of a company requiring their teams
to track the time they spend as part of the tasks in the Agile Project
Management Tool being used?

Yes, when I first started practicing TDD, they wanted me to track how
much of my time was programming and how much was testing. They weren't
happy when I split it 50/50. (Today I'd make that split between
programming and designing. There were 6 or 8 different buckets.)

Post by Greg Robinson
For example, if a user story consists of 5 tasks and task1 was estimated
at 6hours but it only took 3 hours to complete, than the developer is
required to enter the actual effort of 3 hours into the tool for time
tracking purposes.

Isn't it rather silly to track at that level? Do you subtract out for
time spent getting a cup of coffee?

Post by Greg Robinson
I can understand tracking the estimated vs actuals over the course of a
sprint or two in order to help improve team agility and estimation
practices, but I've never heard of it being mandated as a time entry
system. This can be a problem particularly for mature teams that don't
use tasks or task hours.
What have you seen work? What downsides do you see to this?

What I've seen work is to measure the number of team-iterations required
to produce a given release. That tells you how much that release cost,
and can be used for capitalization. Accountants don't generally sweat
the pennies in such calculations. They don't capitalize tasks, but
releases. Unreleased software can't be capitalized.

This presumes that the team is dedicated on the development work. If
they're not, then
1. Ask yourself why not.
2. Measure or estimate how much time is spent on non-capitalizable
work and subtract this.
3. Notice what a PITA it is to do #2 and repeat #1.

-- George

[Cass Dalton]

I work for a government contractor so we are required to track our time.
But the time tracking is essentially at the granularity that was decided
on at proposal or contract award. I have never been in favor of requiring
developers to micromanage their time. It impedes the creativity flow.
Detailed time tracking is Muda (
http://en.wikipedia.org/wiki/Muda_(Japanese_term)). It drags the team
down, and it will drag management down although they won't realize it. I
am not a business person, so I don't pretend to understand the
purpose/value of capitalizing hours spent developing software, but even in
our business where we are required to track time, I have recommended that
our POs and SMs NOT manage developers' time this way. I preach to anyone
who will listen that the team's estimates are a tool for the TEAM to help
them meet commitments. If team members want to get better at estimating
and they like the feedback loop you get from recording actuals beside
estimates, then they should be allowed to use that tool. But I personally
oppose any other use of that tool. Tracking actuals next to estimates for
management purposes can lead to blame from said management. It can lead to
management taking those actuals out of context and generating estimates for
future work without the proper consultation of the developers. It can lead
to expectation of future "similar" capabilities to be developed for the
same number of hours. Essentially, many of the traditional program
management practices that agile tries to avoid can slip back in when you
start tracking hours. Hour tracking is a very Taylorian (
http://en.wikipedia.org/wiki/Frederick_Winslow_Taylor) practice based on
the idea that developer hours are just as much of a homogeneous commodity
as are cam shafts and carburetors. This model of management is rarely in
harmony with the values in the Manifesto.

Just my $0.02
-Cass


On Mon, Dec 16, 2013 at 1:21 PM, George Dinwiddie

Post by George Dinwiddie
Greg,

Post by Greg Robinson
Companies that want to capitalize their expenses for building software
need their development teams to track time they spend on building and
testing software. Has anyone heard of a company requiring their teams
to track the time they spend as part of the tasks in the Agile Project
Management Tool being used?

Yes, when I first started practicing TDD, they wanted me to track how
much of my time was programming and how much was testing. They weren't
happy when I split it 50/50. (Today I'd make that split between
programming and designing. There were 6 or 8 different buckets.)

Post by Greg Robinson
For example, if a user story consists of 5 tasks and task1 was estimated
at 6hours but it only took 3 hours to complete, than the developer is
required to enter the actual effort of 3 hours into the tool for time
tracking purposes.

Isn't it rather silly to track at that level? Do you subtract out for
time spent getting a cup of coffee?

Post by Greg Robinson
I can understand tracking the estimated vs actuals over the course of a
sprint or two in order to help improve team agility and estimation
practices, but I've never heard of it being mandated as a time entry
system. This can be a problem particularly for mature teams that don't
use tasks or task hours.
What have you seen work? What downsides do you see to this?

What I've seen work is to measure the number of team-iterations required
to produce a given release. That tells you how much that release cost,
and can be used for capitalization. Accountants don't generally sweat
the pennies in such calculations. They don't capitalize tasks, but
releases. Unreleased software can't be capitalized.
This presumes that the team is dedicated on the development work. If
they're not, then
1. Ask yourself why not.
2. Measure or estimate how much time is spent on non-capitalizable
work and subtract this.
3. Notice what a PITA it is to do #2 and repeat #1.
-- George
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------

[Dan Greening]

I wrote about agile capitalization without time-tracking here:
http://www.infoq.com/articles/agile-capitalization

Hopefully, that helps.

Dan R. Greening — http://dan.greening.org

Post by Greg Robinson
Companies that want to capitalize their expenses for building software
need their development teams to track time they spend on building and
testing software. Has anyone heard of a company requiring their teams to
track the time they spend as part of the tasks in the Agile Project
Management Tool being used?
For example, if a user story consists of 5 tasks and task1 was estimated
at 6hours but it only took 3 hours to complete, than the developer is
required to enter the actual effort of 3 hours into the tool for time
tracking purposes.
I can understand tracking the estimated vs actuals over the course of a
sprint or two in order to help improve team agility and estimation
practices, but I've never heard of it being mandated as a time entry
system. This can be a problem particularly for mature teams that don't use
tasks or task hours.
What have you seen work? What downsides do you see to this?
Looking for comments or thoughts.
Thanks.
Greg

[s***@gmail.com]

I see it mandates as a time entry system all the time. The shops where I see that are usually somewhat challenged in the trust department. I haven’t ever seen it in a mature team, and my anecdotal experience makes me feel that a team with that kind of requirement probably won’t make it to maturity from an Agile perspective.


From your example, the developer would enter the 3 hours of effort, then be required to prove they did something productive with the other three hours by entering some other task into said system. It turns into a game of “justify my paycheck” and almost always results in overinflated estimates. Or at least that has been what I’ve been observing.






Steve





From: Dan Greening
Sent: ‎Monday‎, ‎December‎ ‎16‎, ‎2013 ‎4‎:‎06‎ ‎PM
To: ***@yahoogroups.com










I wrote about agile capitalization without time-tracking here: http://www.infoq.com/articles/agile-capitalization


Hopefully, that helps.



Dan R. Greening — http://dan.greening.org




On Mon, Dec 16, 2013 at 8:59 AM, Greg Robinson <***@gmail.com> wrote:







Companies that want to capitalize their expenses for building software need their development teams to track time they spend on building and testing software. Has anyone heard of a company requiring their teams to track the time they spend as part of the tasks in the Agile Project Management Tool being used?

For example, if a user story consists of 5 tasks and task1 was estimated at 6hours but it only took 3 hours to complete, than the developer is required to enter the actual effort of 3 hours into the tool for time tracking purposes.

I can understand tracking the estimated vs actuals over the course of a sprint or two in order to help improve team agility and estimation practices, but I've never heard of it being mandated as a time entry system. This can be a problem particularly for mature teams that don't use tasks or task hours.

What have you seen work? What downsides do you see to this?

Looking for comments or thoughts.

Thanks.
Greg

[Dan Greening]

Hi Steve,

"Companies that want to capitalize" is Greg's key phrasing here. This isn't
about the company mistrusting people, this is about helping a company
perform more accurate financial reporting for tax or public accounting
reasons. Some labor cost is "capitalized" (investments that will reap
returns over several years) and other labor is "operational expense" (costs
that contribute only to short term gains). There are tax and financial
reporting benefits that accrue when you more accurately classify. For
public companies, more accurate reporting typically improves market trust.

I may be misunderstanding your comments below, but it seems like you are
saying that I am recommending that people track time. I am definitely not.
The article I wrote shows people how to capitalize work with high levels of
verification, even mixed-mode work, without having to track actuals at all.
The approach I describe passed financial muster from Ernst and Young, a
highly regarded financial auditing group, and its greater accuracy and
verifiability allowed us to capitalize work that would otherwise would be
"conservatively" thrown into the "expense" bucket.

So, in answer to Greg's question, Yes, I have definitely heard of companies
demanding that teams track actuals in order to better capitalize work, but
it is not a good idea. When I worked at Citrix Online, there were people
demanding that we track actuals for capitalization, and I invented the
approach I describe to avoid it. Typically "actuals tracking" requires
engineers to estimate their activities weekly, on time-cards, as hourly
estimates of time. The result is guess-work and less accurate, in my
opinion, than proportionally allocating team-team by relative story point
proportion. By forcing engineers to track actuals, you distract engineers
from focusing on the engineering problems, and thus sacrifice productivity.
Our auditors seemed to agree. After running this way for two quarters, they
realized how our approach was highly verifiable, that every team member
could verify the capitalization we were reporting. They were extremely
happy with us, quarter after quarter, because we could point to all the
data, and we provided clear guidance on our process for gathering that data.

See: http://senexrex.com/agile-capitalization/

Dan Greening, PhD
Managing Director, Senex Rex LLC, http://senexrex.com

Post by s***@gmail.com
I see it mandates as a time entry system all the time. The shops where I
see that are usually somewhat challenged in the trust department. I
haven’t ever seen it in a mature team, and my anecdotal experience makes me
feel that a team with that kind of requirement probably won’t make it to
maturity from an Agile perspective.
From your example, the developer would enter the 3 hours of effort, then
be required to prove they did something productive with the other three
hours by entering some other task into said system. It turns into a game
of “justify my paycheck” and almost always results in overinflated
estimates. Or at least that has been what I’ve been observing.
Steve
*Sent:* ‎Monday‎, ‎December‎ ‎16‎, ‎2013 ‎4‎:‎06‎ ‎PM
http://www.infoq.com/articles/agile-capitalization
Hopefully, that helps.
Dan R. Greening — http://dan.greening.org

Post by Greg Robinson
Companies that want to capitalize their expenses for building software
need their development teams to track time they spend on building and
testing software. Has anyone heard of a company requiring their teams to
track the time they spend as part of the tasks in the Agile Project
Management Tool being used?
For example, if a user story consists of 5 tasks and task1 was estimated
at 6hours but it only took 3 hours to complete, than the developer is
required to enter the actual effort of 3 hours into the tool for time
tracking purposes.
I can understand tracking the estimated vs actuals over the course of a
sprint or two in order to help improve team agility and estimation
practices, but I've never heard of it being mandated as a time entry
system. This can be a problem particularly for mature teams that don't use
tasks or task hours.
What have you seen work? What downsides do you see to this?
Looking for comments or thoughts.
Thanks.
Greg

[s***@gmail.com]

My mistake, I replied to the wrong part of this thread. Sorry about that. I agree with what you are saying. I was answering Greg's question. I'll be more careful next time! 😊






Sent from Windows Mail





From: Dan Greening
Sent: ‎Monday‎, ‎December‎ ‎16‎, ‎2013 ‎10‎:‎56‎ ‎PM
To: ***@yahoogroups.com










Hi Steve,

"Companies that want to capitalize" is Greg's key phrasing here. This isn't about the company mistrusting people, this is about helping a company perform more accurate financial reporting for tax or public accounting reasons. Some labor cost is "capitalized" (investments that will reap returns over several years) and other labor is "operational expense" (costs that contribute only to short term gains). There are tax and financial reporting benefits that accrue when you more accurately classify. For public companies, more accurate reporting typically improves market trust.



I may be misunderstanding your comments below, but it seems like you are saying that I am recommending that people track time. I am definitely not. The article I wrote shows people how to capitalize work with high levels of verification, even mixed-mode work, without having to track actuals at all. The approach I describe passed financial muster from Ernst and Young, a highly regarded financial auditing group, and its greater accuracy and verifiability allowed us to capitalize work that would otherwise would be "conservatively" thrown into the "expense" bucket.


So, in answer to Greg's question, Yes, I have definitely heard of companies demanding that teams track actuals in order to better capitalize work, but it is not a good idea. When I worked at Citrix Online, there were people demanding that we track actuals for capitalization, and I invented the approach I describe to avoid it. Typically "actuals tracking" requires engineers to estimate their activities weekly, on time-cards, as hourly estimates of time. The result is guess-work and less accurate, in my opinion, than proportionally allocating team-team by relative story point proportion. By forcing engineers to track actuals, you distract engineers from focusing on the engineering problems, and thus sacrifice productivity. Our auditors seemed to agree. After running this way for two quarters, they realized how our approach was highly verifiable, that every team member could verify the capitalization we were reporting. They were extremely happy with us, quarter after quarter, because we could point to all the data, and we provided clear guidance on our process for gathering that data.



See: http://senexrex.com/agile-capitalization/





Dan Greening, PhD
Managing Director, Senex Rex LLC, http://senexrex.com
Email: ***@senexrex.com Phone: [phone], Skypeid: drgreening



On Mon, Dec 16, 2013 at 7:57 PM, <***@gmail.com> wrote:









I see it mandates as a time entry system all the time. The shops where I see that are usually somewhat challenged in the trust department. I haven’t ever seen it in a mature team, and my anecdotal experience makes me feel that a team with that kind of requirement probably won’t make it to maturity from an Agile perspective.




From your example, the developer would enter the 3 hours of effort, then be required to prove they did something productive with the other three hours by entering some other task into said system. It turns into a game of “justify my paycheck” and almost always results in overinflated estimates. Or at least that has been what I’ve been observing.






Steve





From: Dan Greening
Sent: ‎Monday‎, ‎December‎ ‎16‎, ‎2013 ‎4‎:‎06‎ ‎PM
To: ***@yahoogroups.com











I wrote about agile capitalization without time-tracking here: http://www.infoq.com/articles/agile-capitalization


Hopefully, that helps.



Dan R. Greening — http://dan.greening.org




On Mon, Dec 16, 2013 at 8:59 AM, Greg Robinson <***@gmail.com> wrote:







Companies that want to capitalize their expenses for building software need their development teams to track time they spend on building and testing software. Has anyone heard of a company requiring their teams to track the time they spend as part of the tasks in the Agile Project Management Tool being used?

For example, if a user story consists of 5 tasks and task1 was estimated at 6hours but it only took 3 hours to complete, than the developer is required to enter the actual effort of 3 hours into the tool for time tracking purposes.

I can understand tracking the estimated vs actuals over the course of a sprint or two in order to help improve team agility and estimation practices, but I've never heard of it being mandated as a time entry system. This can be a problem particularly for mature teams that don't use tasks or task hours.

What have you seen work? What downsides do you see to this?

Looking for comments or thoughts.

Thanks.
Greg

[Ron Jeffries]

Hi Dan,

Post by s***@gmail.com
I wrote about agile capitalization without time-tracking here: http://www.infoq.com/articles/agile-capitalization

Nice article. I recommend it. Two things:

First, it's long and complex. For some readers, it's probably ideal. For others -- many of the folks here -- it's too much all at once. I'd love to see a shorter version. In particular, since often capitalization is a given, much of the rationale for it could perhaps be left out or deferred to an appendix. Just my thoughts, perhaps useless.

Second, I am not as positive about capitalization as you seem to be, nor as negative about expensing. My experience with capitalization was that from the viewpoint of someone trying to get something done, capitalizing has short term advantages and serious long-term disadvantages. After a few years of capitalizing, you have to start amortizing things. It's hard to make a case for a ten or twenty-year lifespan for software, so you're likely to need to write it all off over perhaps five years.

I wound up, in the company I was VP R&D for, with a budget that was well over 50% amortization. The result was less money for real work, reduced staffing, slower progress. Ultimately, dissolution.

If I were to enter that world again, I would argue strongly -- more likely insist -- on expensing development. Between the risks of bad product ideas, rapid technological change, and the whims of the market, only some unknown fraction of development should be capitalized anyway, over some short and unknown period. I'd rather suffer the small risk of lower stock prices in aid of building a solid company based on reality.

But that's just me. If I had to capitalize, I'd do much as you say. With you, I completely agree that hours counting is silly and unnecessary. Counting stories or points can work. Most companies already know what they're paying for each product anyway, and if they do, that number works just fine.

Thanks,

Ron Jeffries
www.XProgramming.com
There's no word for accountability in Finnish.
Accountability is something that is left when responsibility has been subtracted.
--Pasi Sahlberg

[Charles Bradley - Professional Scrum Trainer and Coach]

Dan,

Post by Ron Jeffries
First, it's long and complex. For some readers, it's probably ideal.

+1, great for some readers.

Post by Ron Jeffries
I'd love to see a shorter version

+1.  "The Agile Finance Primer"  ?  PDF, downloadable, with all of your marketing schpeel included but not intrusive? 


 
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
ScrumCrazy.com

Post by Ron Jeffries
________________________________
Sent: Tuesday, December 17, 2013 7:29 AM
Subject: Re: [SCRUMDEVELOPMENT] Time tracking for building software
Hi Dan,
I wrote about agile capitalization without time-tracking here: http://www.infoq.com/articles/agile-capitalization
First, it's long and complex. For some readers, it's probably ideal. For others -- many of the folks here -- it's too much all at once. I'd love to see a shorter version. In particular, since often capitalization is a given, much of the rationale for it could perhaps be left out or deferred to an appendix. Just my thoughts, perhaps useless.
Second, I am not as positive about capitalization as you seem to be, nor as negative about expensing. My experience with capitalization was that from the viewpoint of someone trying to get something done, capitalizing has short term advantages and serious long-term disadvantages. After a few years of capitalizing, you have to start amortizing things. It's hard to make a case for a ten or twenty-year lifespan for software, so you're likely to need to write it all off over perhaps five years.
I wound up, in the company I was VP R&D for, with a budget that was well over 50% amortization. The result was less money for real work, reduced staffing, slower progress. Ultimately, dissolution.
If I were to enter that world again, I would argue strongly -- more likely insist -- on expensing development. Between the risks of bad product ideas, rapid technological change, and the whims of the market, only some unknown fraction of development should be capitalized anyway, over some short and unknown period. I'd rather suffer the small risk of lower stock prices in aid of building a solid company based on reality.
But that's just me. If I had to capitalize, I'd do much as you say. With you, I completely agree that hours counting is silly and unnecessary. Counting stories or points can work. Most companies already know what they're paying for each product anyway, and if they do, that number works just fine.
Thanks,
Ron Jeffrieswww.XProgramming.com
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg

[Dan Greening]

There are a number of companies who expense all software development, and
others who do not. From a practical point of view, there are benefits in
each direction. Ron, I can definitely see how R&D in a volatile or highly
competitive sector could be best expensed. On the other hand, there's lots
of software that has been in use for decades (some will barf, but let me
just say "insurance companies"). Even in SaaS software, Citrix Online has
some long-standing products, and there's plenty of software that's been in
use for over 5 years there.

From a legal standpoint, you are really supposed to report which labor

costs were for long-term investment, and which were short. This helps the
reported balance sheet and profit & loss statements communicate more
transparently what is happening inside a company.

Thanks everyone for the kind thoughts about writing more on agile
accounting.

Dan R. Greening — http://dan.greening.org

Hi Dan,
http://www.infoq.com/articles/agile-capitalization
First, it's long and complex. For some readers, it's probably ideal. For
others -- many of the folks here -- it's too much all at once. I'd love to
see a shorter version. In particular, since often capitalization is a
given, much of the rationale for it could perhaps be left out or deferred
to an appendix. Just my thoughts, perhaps useless.
Second, I am not as positive about capitalization as you seem to be, nor
as negative about expensing. My experience with capitalization was that
from the viewpoint of someone trying to get something done, capitalizing
has short term advantages and serious long-term disadvantages. After a few
years of capitalizing, you have to start amortizing things. It's hard to
make a case for a ten or twenty-year lifespan for software, so you're
likely to need to write it all off over perhaps five years.
I wound up, in the company I was VP R&D for, with a budget that was well
over 50% amortization. The result was less money for real work, reduced
staffing, slower progress. Ultimately, dissolution.
If I were to enter that world again, I would argue strongly -- more likely
insist -- on expensing development. Between the risks of bad product ideas,
rapid technological change, and the whims of the market, only some unknown
fraction of development should be capitalized anyway, over some short and
unknown period. I'd rather suffer the small risk of lower stock prices in
aid of building a solid company based on reality.
But that's just me. If I had to capitalize, I'd do much as you say. With
you, I completely agree that hours counting is silly and unnecessary.
Counting stories or points can work. Most companies already know what
they're paying for each product anyway, and if they do, that number works
just fine.
Thanks,
Ron Jeffries
www.XProgramming.com
There's no word for accountability in Finnish.
Accountability is something that is left when responsibility has been subtracted.
--Pasi Sahlberg

[Kurt Häusler]

Hi Greg,

most companies I have worked at that used Scrum required such time tracking. Mostly because the information was required for their time & materials billing approach. Sometimes to give the PMs an idea about how much they need to scale developer estimates (I mean initial hour estimates required to write a customer offer, not the agile estimating used in sprint and release planning) in order to get numbers they can put in a offer or contract.

I am opposed to it, and see it only leading to many types of dysfunction. It simply doesn’t suit the nature of the work.

Cheers,

Kurt

Companies that want to capitalize their expenses for building software need their development teams to track time they spend on building and testing software. Has anyone heard of a company requiring their teams to track the time they spend as part of the tasks in the Agile Project Management Tool being used?
For example, if a user story consists of 5 tasks and task1 was estimated at 6hours but it only took 3 hours to complete, than the developer is required to enter the actual effort of 3 hours into the tool for time tracking purposes.
I can understand tracking the estimated vs actuals over the course of a sprint or two in order to help improve team agility and estimation practices, but I've never heard of it being mandated as a time entry system. This can be a problem particularly for mature teams that don't use tasks or task hours.
What have you seen work? What downsides do you see to this?
Looking for comments or thoughts.

[Charles Bradley - Professional Scrum Trainer and Coach]

Greg,

You might also want to see this article about Scrum time tracking written by Scrum Co-Creator Jeff Sutherland:

http://scrum.jeffsutherland.com/2007/03/time-tracking-is-anti-scrum-what-do-you.html


 
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
ScrumCrazy.com

Post by Ron Jeffries
________________________________
Sent: Tuesday, December 17, 2013 7:14 AM
Subject: Re: [SCRUMDEVELOPMENT] Time tracking for building software
Hi Greg,
most companies I have worked at that used Scrum required such time tracking. Mostly because the information was required for their time & materials billing approach. Sometimes to give the PMs an idea about how much they need to scale developer estimates (I mean initial hour estimates required to write a customer offer, not the agile estimating used in sprint and release planning) in order to get numbers they can put in a offer or contract.
I am opposed to it, and see it only leading to many types of dysfunction. It simply doesn’t suit the nature of the work.
Cheers,
Kurt

Companies that want to capitalize their expenses for building software need their development teams to track time they spend on building and testing software.  Has anyone heard of a company requiring their teams to track the time they spend as part of the tasks in the Agile Project Management Tool being used?
For example, if a user story consists of 5 tasks and task1 was estimated at 6hours but it only took 3 hours to complete, than the developer is required to enter the actual effort of 3 hours into the tool for time tracking purposes.
I can understand tracking the estimated vs actuals over the course of a sprint or two in order to help improve team agility and estimation practices, but I've never heard of it being mandated as a time entry system.  This can be a problem particularly for mature teams that don't use tasks or task hours.
What have you seen work?  What downsides do you see to this?
Looking for comments or thoughts.

------------------------------------
    (Yahoo! ID required)

[Greg Robinson]

Thank you to all that have responded! Your feedback and articles have been
tremendously helpful!

Greg
On Dec 17, 2013 2:38 PM, "Charles Bradley - Professional Scrum Trainer and

Post by Charles Bradley - Professional Scrum Trainer and Coach
Greg,
You might also want to see this article about Scrum time tracking written
http://scrum.jeffsutherland.com/2007/03/time-tracking-is-anti-scrum-what-do-you.html
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
ScrumCrazy.com <http://www.scrumcrazy.com/>
------------------------------
*Sent:* Tuesday, December 17, 2013 7:14 AM
*Subject:* Re: [SCRUMDEVELOPMENT] Time tracking for building software
Hi Greg,
most companies I have worked at that used Scrum required such time
tracking. Mostly because the information was required for their time &
materials billing approach. Sometimes to give the PMs an idea about how
much they need to scale developer estimates (I mean initial hour estimates
required to write a customer offer, not the agile estimating used in sprint
and release planning) in order to get numbers they can put in a offer or
contract.
I am opposed to it, and see it only leading to many types of dysfunction.
It simply doesn’t suit the nature of the work.
Cheers,
Kurt

Post by Greg Robinson
Companies that want to capitalize their expenses for building software

need their development teams to track time they spend on building and
testing software. Has anyone heard of a company requiring their teams to
track the time they spend as part of the tasks in the Agile Project
Management Tool being used?

Post by Greg Robinson
For example, if a user story consists of 5 tasks and task1 was estimated

at 6hours but it only took 3 hours to complete, than the developer is
required to enter the actual effort of 3 hours into the tool for time
tracking purposes.

Post by Greg Robinson
I can understand tracking the estimated vs actuals over the course of a

sprint or two in order to help improve team agility and estimation
practices, but I've never heard of it being mandated as a time entry
system. This can be a problem particularly for mature teams that don't use
tasks or task hours.

Post by Greg Robinson
What have you seen work? What downsides do you see to this?
Looking for comments or thoughts.

------------------------------------
(Yahoo! ID required)

[Reaves, Chuck]

We use Version One at my company to enter our time for each task within a User Story...and this is mandatory at our company.

From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of Greg Robinson
Sent: Monday, December 16, 2013 10:59 AM
To: ***@yahoogroups.com
Subject: [SCRUMDEVELOPMENT] Time tracking for building software



Companies that want to capitalize their expenses for building software need their development teams to track time they spend on building and testing software. Has anyone heard of a company requiring their teams to track the time they spend as part of the tasks in the Agile Project Management Tool being used?

For example, if a user story consists of 5 tasks and task1 was estimated at 6hours but it only took 3 hours to complete, than the developer is required to enter the actual effort of 3 hours into the tool for time tracking purposes.

I can understand tracking the estimated vs actuals over the course of a sprint or two in order to help improve team agility and estimation practices, but I've never heard of it being mandated as a time entry system. This can be a problem particularly for mature teams that don't use tasks or task hours.

What have you seen work? What downsides do you see to this?

Looking for comments or thoughts.

Thanks.
Greg

[s***@gmail.com]

Disclaimer: I work for VersionOne



Just so we don’t end up “blaming the tool”, there is nothing about VersionOne that requires tracking time for a task. As a matter of fact, when I am coaching folks who are using the tool, I recommend against it unless absolutely necessary.






Sent from Windows Mail





From: Reaves, Chuck
Sent: ‎Monday‎, ‎December‎ ‎16‎, ‎2013 ‎10‎:‎04‎ ‎AM
To: ***@yahoogroups.com











We use Version One at my company to enter our time for each task within a User Story
and this is mandatory at our company.





From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of Greg Robinson
Sent: Monday, December 16, 2013 10:59 AM
To: ***@yahoogroups.com
Subject: [SCRUMDEVELOPMENT] Time tracking for building software








Companies that want to capitalize their expenses for building software need their development teams to track time they spend on building and testing software. Has anyone heard of a company requiring their teams to track the time they spend as part of the tasks in the Agile Project Management Tool being used?

For example, if a user story consists of 5 tasks and task1 was estimated at 6hours but it only took 3 hours to complete, than the developer is required to enter the actual effort of 3 hours into the tool for time tracking purposes.

I can understand tracking the estimated vs actuals over the course of a sprint or two in order to help improve team agility and estimation practices, but I've never heard of it being mandated as a time entry system. This can be a problem particularly for mature teams that don't use tasks or task hours.

What have you seen work? What downsides do you see to this?

Looking for comments or thoughts.

Thanks.
Greg