Need to measure time spent by team members in a project
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?
* 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.
> 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.
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.
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.
Thank you Christiaan, I'll try to adopt the team measurement instead of people.