How can we track working hours?

Why do you want to track overtime? Who would make use of these metrics?

The value lies in the increment being produced. Isn't it up to a Development Team to forecast the delivery of that increment and to self-organize accordingly?

Hello,

First of all thank you.

Yes you are right. However, even if the development team is self managed, they are full-time employees and it may be required sometimes for the upper level management to monitor the progress of their work performans via outputs. Lets assume, a team is working more than regular working hrs (it may just because they want) and complete the tasks very fast. After a while another team starts a similiar project and use their estimation as a base for their estimation which may cause a failure. It may also cause bad performance chart compared to the other team's performance.

I am not sure, if I could explain it perfectly. I know this is more related with management level instead of scrum teams. I am just wondering, if there any way to track the team or individual performance?

You can track velocity trends of the team itself (intra-team not inter-team) over sprints.

I could be dead wrong here: velocity signatures of teams will vary due to many reasons (e.g. depth of skills, tenure of the team).

Any attempt to establish a proxy measure of value (such as working hours or velocity) should be challenged as an impediment.

The hours worked by team members are up to each team; these hours do not measure the value of the work that the team completes nor do they proxy for its performance. Velocity can be used by a team to help forecast how much work it can take on, but it is not a measure of the value that the team delivers.

Here are some questions to consider. Why is the Product Owner failing to account for the value delivered to stakeholders, so that proxy measures...such as hours worked...are thought to be necessary? Why isn't the Development Team responsible for managing its own performance and its optimization? What is the Scrum Master doing to coach more appropriate organizational behaviors?

"You can track velocity trends of the team itself (intra-team not inter-team) over sprints. "

Clarification: "You" meant the development team i.e. the development team could/should track its velocity during a sprint and from sprint-to-sprint . The development team should also track its defect metrics and code quality metrics as gauges of quality of the increment (delivered or "in development").

The insights that Sr. Management typically look for (based on my exp. with large and mega enterprises in N. America):

-- Are we delivering value to our customers (and how well)? This question deals with the "what" - whether the organization is building the right products/services that solve customer's problems and meet their needs (not necessarily their wants)

-- How well are we building these products/services? This question deals with the "how" of the delivery i.e. the efficiency & effectiveness of the development process

For example, simple insightful metrics can be defined/implemented to answer question 1 (e.g. pace of innovation, customer satisfaction, usage related metrics, etc.)

Quality metrics (e.g. production defect metrics) is a key metric that senior execs monitor to gain insight about Question 2

Ultimately, agile product development's goal is to deliver valuable, high-quality software to customers. So, both value and quality need to be monitored.

There might be different situations in life and different moments in scrum adoption process.

One of the easiest ways how to show what team was doing during sprint is to report whole sprint (8h during day) spent on this particual sprint goal delivery. You can subtract up to 10% on refining next one. And it might not solve organizational challenge at all. I saw once situation when management was interested in finding out how maintenance, releasing, bug solving impact on delivery of new increments. Purpose was good and proper reasoning had to be applied.