Is there a way of measuring the cost of agile development without recording the amount of time it took you to do a task?

Question

Picture the scene, a business is thinking about using the Scrum methodology for agile development. They have implemented the Scrum for Team Systems and everyone is very happy with it. However the business wants to capitalise their development cost and have asked for Scrum backlog work item template to be modified to include the time taken to do the task. The idea being that they need to know how much time a developer spent doing productive work I.E. how much time they spent adding new features.

The problem that some people in the business have with this (including myself) is that recording how mush time you have spent on something kind of defeats the object of Scrum. All I want to know from a lead developer point of view is that we have this much time to do this much work. We record how much time is left on the task and we can see how far we are away from meeting our objectives.

Maybe I am missing the point? You tell me. If however someone out there knows a way in which we can work without recording the exact amount of time we spent doing something and still please the people that invest the money then your answer would be much appreciated.

Answer 1

We have been using Agile/SCRUM for about 2 years now, and we've never recorded actuals.

It seems that every now and then attempts are made to get everyone to record this information. Usually this is as a result of a poor sprint where the blame lies squarely at poor estimation. But it's too easy to forget to mark these down - although I'm sure with enough 'gentle prodding' it would become habit.

The idea that I see again and again - and the one that I agree with - is that your velocity should answer any question you (or the product owners) need to ask regarding progress on tasks.

Answer 2

Scrum, and other agile development methods, work best when there is trust between the people involved on both sides. Management needs to trust that developers work hard and work well. Developers need to trust that management respects their input and asks them to do appropriate work based on business needs. Absent this trust, your process will be dysfunctional. No environment is perfect, but at some point the trust issues may get bad enough that it becomes unworkable.

Having said that, there are any number of things that I, as a developer, have to do "just because." I, for instance, have to do just this sort of thing because that's the way the whole organization works -- developers, included. I can live with that. I would say track your time, but plan from sprints. Record your "unproductive" time meaningfully -- as technology research, office tasks, etc. -- whatever they may be -- so that the business folks understand that you are always productive even when not developing code.

EDIT Oh -- and if the time tracking activity is particularly onerous, like filling out detailed daily logs, make sure you keep track of the amount of time you spend tracking your time very clearly so they know how much the activity is costing.

Answer 3

Scrum is not rigid, its all about adaptability and what suites your needs.

Why don't you estimate stories in hours instead of story points. We too faced the same situation and we started estimating in hours. Everyday against that estimated hours developer log how much time they worked on a story. On daily basis one can see how much more time the story need and in the end one can see the estimate and actual time taken. We used XPlanner to track this and it takes a minute for developer to log time daily. Based on this information you can always measure the velocity which will help in next iteration.

Apart from project related stories we log time lost in other activities, e.g. meetings, environment down, production support, etc. Over a period of time this information gave us lot of information and we managed to reduce that lost time a lot.

Answer 4

The first question is - are you a consulting shop, or an internal IT shop. If the former, then actuals may be necessary to allow them to bill the customers correctly. If the latter, and you all are salaried, then the reasons aren't as clear. I'm always suspect of any manager wanting to know "how much time a programmer spent doing productive work". It's a metric, and one of the key things I tell teams with any form of agile development is that metrics should be captured for clear purposes that the team agrees with.

I would ask what the "question behind the question" is - or what management is really looking for. Why are they concerned about developer productivity? Are they having a hard time explaining to their managers what is going on? Are there team metrics that could be provide that you could generalize?

In short - your manager could be considered a customer of the team, so find out what your customer wants, and figure out the best way - as a team - to provide it.

Answer 5

As a development manager, I am both interested in making sure that development runs smoothly (via Scrum) and that time is accounted for per project so we know where we are spending our money (Time Tracking).

Therefore, during a sprint team members are asked to update the amount of time remaining on outstanding tasks to compute the burndown chart. It should not take more than a couple of minutes. Since we are using Scrum, the team decides on the tasks and I don't care who is doing what as long as we have a burndown chart.

I also ask them to track their time per project and this is not very detailled. I don't want to track every minute of their time. This information is used to get a feel for how long it takes to release a version or much money goes into developing a product.

Since we are using Scrum time tracking is very simple since all members of a team work on the same project for long period of time.