Skip to main content

Need to measure time spent by team members in a project

Last post 10:45 am December 9, 2014 by Fernando Moyano
5 replies
09:03 am November 21, 2014

I have a need, that as far as I have seen, is not very common in  agile developments.

I'm in charge of scrum implementation in my company, and we are on track, but now, the Project Manager wants to know the cost in hours of each project, ie, how many hours did each person on each project, and if possible, to each user story.

The goal is to measure project costs upon completion (or intermediate stages) and have this information metrics serve to estimate future projects.

I read somewhere some issues regarding team development speed, but I'm don't really know how it is measured.

In summary, I would like help on these points:
* In scrum, what is the recoomendation in order to register and check the number of hours invested by each team member on a project?
* How team speed is measured?


10:18 am November 21, 2014

* In scrum, what is the recoomendation in order to register and check the number of hours invested by each team member on a project?


Do not EVER do that ! Useless, time consuming and it will destroy any attempt to grow a self-organized team.


* How team speed is measured?

Use the velocity (of the team, not of the team members). Be aware that velocity depends on your DOD... Do not try to toggle velocity.


01:47 pm November 21, 2014

> The goal is to measure project costs upon
> completion (or intermediate stages)

If that is the goal then that is what you should measure. You can measure the cost of producing each Sprint Increment until such time as the product is deemed to be complete. These figures can then be used to inform future stakeholders regarding sprint operating costs should that same team be re-employed in the development of a comparable product.

Measuring person hours is inappropriate unless the intention is to sum them up for that purpose. The production of each increment *must* be viewed as a timeboxed team effort.

Working out the cost per user story isn't a useful measure, as the granularity, effort, and complexity will vary according to the product being developed.


12:21 am November 22, 2014

Using past project to make a prediction for future project is a non-sense in a software development world. If you think that the future is the interpolation of the present you will be dead wrong becaue you never make the same software twice and you never use the same exact technology more than once. Measure value delivered to customers instead as that is the only thing that matters.


03:56 pm November 23, 2014

Team speed is measured as estimated & completed PBI’s in shippable product increments. The estimation metric is team specific.

One metric could be user story points. A team itself decides the definition of a story point. It could be men days in an ideal working context. And to illustrate that it is team specific and not absolute, people have suggested other metrics like t-shit size (S, M, L, XL, XXL), dog breed (Chichuachua, dachshund, Golden retriever, German Sheppard, Danisch Dog).

(Google on planning poker, burn down chart )

The whole idea about scrum is to organize the most rare and valuable assets (e.g. time and people) to create the most value for the client/customer and the company.

Scrum is by definition a team effort. It is a framework to create value. Measuring the individual team members will destroy the concept of self organizing capabilities of a team.

A Kanban board or a release burn down chart may make your management more comfortable.

Or in short: budget and time are fixed. Additional functionality is cancelled when not adding enough value.
Hopes this helps.


10:45 am December 9, 2014

Thank you Christiaan, I'll try to adopt the team measurement instead of people.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.