Evaluation of Team performance
I am facing a problem with evaluating the performance of my development team. We are working on a cross-platform mobile app, and I want to track real performance statistics to understand whether the team is underperforming or doing well. However, I am not sure how to measure (except story points) this or which metrics I should use. How can you solve this issue or already solved?
Story points are of no use to you: they only help the Developers get their arms around how much work they can take on each Sprint to meet a Sprint Goal.
Are those Sprint Goals being met, and are Done increments of immediate usable quality being provided each and every Sprint? Scrum is commitment driven.
If the Developers are not meeting these commitments, find out why. Perhaps there are organizational impediments holding them back.
@Ian's suggestion is spot on. Who really cares if a team burns story points if there is nothing being delivered that the stakeholders want and need at a time they want and need it.
Story points are an estimate at a specific point in time based upon the information available at that time. As soon as work begins, those estimates are no longer valid because new information has been obtained. Even if you were to use flow metrics (I recommend you read these books to learn about them - https://actionableagile.com/books/) you still know nothing about the true performance of the team. I am assuming that the performance that the organization wants is something the makes money. If you aren't delivering value that the stakeholders/customers/users want and need, then you won't be making money. Stop trying to put the emphasis on whether the development team is busy and start putting the emphasis on whether the stakeholders/customer/users are happy.
I also think Ian's suggestion is spot on here.
I'd add that, regardless of what you do, story points are the wrong measure. Consider that story points are initial estimates of the work based on what is known at the time. Unless you invest the time to update them after the work is completed (which I wouldn't recommend, as there are better uses of the team's time), they do not accurately reflect the actual time or effort required to complete the work. At best, story points are an initial planning tool, and I'm not even convinced that they are really useful for that for many teams.
I think it's key to understand what "doing well" means. Tracking whether the team achieved the Sprint Goal or not is one option that inherently comes from the Scrum framework. However, even that doesn't say anything about if the Sprint Goal was valuable enough to warrant the cost of running a Sprint - this information may not be available until after the Sprint is complete, though. There may be other options, like understanding where the team is spending their time and maximizing the time on value-add activities. However, these options aren't universally defined and are likely ot be unique to each team's context.
I wanted to add another resource for you to read. It occurred to me that it might be helpful for you as well.
Evidence-Based Management might be a useful read for you. It helped me understand how to discuss the topic of evaluating the organizations ability to be agile with more than one executive.