New bossman is looking for KPIs.

We're an agile team who build a back end system for a large corporation. Specifically the system we build is used by the sales guys when they are putting through a sale. I have no idea where to start with KPIs.

Can't measure number of sales as that's down to the salesmen. Can't measure speed of sale as again that's down to the salesman and how much they chat.

Any ideas?

Revenue per sale?

Are you a BA or a Dev? Dev's aren't responsible for identifying KPIs.

You are developing a backend software. Just measure the # closed but per sprint iteration at every sprint review. If no bugs are present, there might be some usability issue, just ask the manager to hold a monthly satisfaction survey among the salesman and use that as kpi.

KPI are there to measure team performance, not application's. If the app is delivered and working, you should measure KPI on the new project you are shipping.

@mmcorreia not applicable to us as we don't set the prices and are not involved in the selling process.

@iAmNaN I am/was a developer but I am BA in this role.

@-eth yeah I'm closing in on something like that. Looking to possibly measure code complexity (app is a monolith and legacy = horror story) and test coverage.

Not sure if I agree about KPIs measuring the team and not the app. For example the guys who built the consumer front end are kpi 'd on conversions to click through. And I agree with that.

I understood you were looking for KPIs on the business itself to show on a dashboard...

If it's just about the team measure mean speed (the amount of donne/closed complexity points the team can make in a average Sprint - usually the mean of the last N sprints).

For this you should cost every task in complexity points and not hours.

You can also measure the amount of rework per task. And measure how much of the work is based on new features and on production support.

Test coverage is a good KPI and successfull automatic test per merge in master (new code does not break functionality) too

@GigaMick
Well, of course choose whatever floats your boat, personally I choose to monitor performance on projects during development and polishing phase, but if you prefer to test satisfaction on closed project...why not.
Actually, the company policy is to monitor activity during development stages and not on usage/appreciation of closed items...maybe your policies regards measuring projects and not teams? Let me know, I might propose the paradigm shift