I read scrum kanban and don't understand

- What is the average unit cycle time? hour or minute or day

The average cycle time will depend on your context. I'm used to seeing cycle time expressed in days, but there may be organizations that can measure it in hours. You will need to start measuring cycle time to decide what units are best to express your cycle time in.

- What is the average throughput? What is the unit? What good story points

Throughput is, in my experience, usually measured in units of work, often Product Backlog Items, per unit of time, often Sprint. Simply, the team's throughput is the number of Product Backlog Items they complete per Sprint. Some teams or organizations may measure throughput in other units of time, though, such as weeks.

You could measure throughput in story points, but once you start using flow metrics, like throughput and cycle time, you can use those instead of story points to plan work for a Sprint and you no longer need to size or estimate work in story points.

- How is the work being done? What is the unit?

The unit is a Product Backlog Item. Tracking cycle time begins when the team starts work on the PBI and stops when the PBI conforms to the team's Definition of Done.

I want to use cycle time to measure dev productivity.

Why? How do you intend to use that data?

@Ian Mitchell

Because my company uses Jira for work, and I found out that there is a control chart, I learned from many sources, this chart is one of the important metrics to evaluate dev productivity based on cycle time, so I learn about it.

You need to be careful when talking about productivity, especially in the context of agility. Productivity tends to be about getting work done. A productive team - that is, a team that gets a lot of things (perhaps Product Backlog Items, in the context of Scrum) done - may not be getting the right things done. Measuring cycle time and throughput would give you information about how long it takes to get a unit of work done and how much work the team can do per unit of time, but it will say nothing about if that work is being done well or if it's the right work to address stakeholder needs.

Once you do have cycle time, how you use it is also important. You cannot blindly "improve cycle time". Your external stakeholders can only consume changes at a certain rate. Producing outputs, even the right outputs, faster than your stakeholders can consume them and provide feedback wouldn't get you significant gains. You first need to understand what cycle time and throughput makes sense in your environment. If you are producing slower than that rate, you then need to understand why, since there could be any number of factors that influence the cycle time of work, including some that are beyond the control of the development teams.

The Jira Control Chart is fairly limited compared to a Scatter Plot. The Scatter Plot provides probabilities which is missing in the Control Chart. Perhaps investigate using the Actionable Agile plugin for Jira.

I think Thomas has covered most of the details but I'd like highlight a few points for your consideration

. Average unit cycle time  

there is no identical object hence we should not compared object A and B development time directly (benchmarking)

we should encourage development team to provide better estimation / object 

. Average throughput / unit / story point 

We should focus on progress of product backlog item / sprint cycle example: 50% are done at first sprint

story point is good for initial estimation but there is not much value to keep updating story point according to changes

. How the work being done? what is the unit 

Please ensure that DOD are accepted by stakeholder before we declare it is completed 

the unit will serve as reference only because we should aim for a PBI done rather than development done only