Source: stackify april 18, 2017
Ordered by how many managers use it.
-
[10] high speed, or productivity == velocity (eg: scrum story points, team velocity, team delivers more than it did before)
- The buy-in from your team on Time tracking can be hard. It has to pitch in a manner that this is used to grow individually and identify bottlenecks in the software, as opposed to identifying slow developers. With a good team, this buy-in comes easy. This works only if the manager trusts his team.
-
[9] high volume of code released, Commits/Check-ins, Commit-to-Deploy Time (CDT), cycle time, open-close time
- Most fast-moving organizations (e.g., Facebook, Amazon) deploy hundreds of times a day. For smaller organizations, daily deployments would be a good goal. the smaller your commits are, the faster they can get into production, and the faster you’ll be able to fix things when they go wrong
-
[7] high code quality (performance, security, impact on maintenence, bug free, feature complete, according to spec, code flexibility and extensibility)
- pair programming (both agree that code is high standard)
- Pull Requests analysis (i.e. code reviews)
- Imagine a case where there are four suggestions to do something one way as opposed to another. If the suggestion is something that can be summed up in a code linting rule, then the developer will see their error before they make a future PR and not waste others’ time.
- Also, if people are nit-picky with their PR suggestions, it’s often a good indicator that there might be some ego issues on your team.
-
[3] released on time, dev hours, hitting Release Dates – The team’s ability to communicate and agree to a product roadmap and then hit the dates for releases
-
[3] high ROI, Profitability – Increasing business revenue and/or cutting costs
-
[3] low cost to implement, meet budget
-
[3] high up time, low number of bugs/tickets raised
-
[2] meet business goals
-
[2] Customer is "satisfyed"
-
[1] more Lines of code commited (LOC)
-
[1] developer interview outcomes
- scheduling short meetings with the developers we are evaluating, listening closely what problems they are facing with. We are also asking them how helpful and knowledgeable the rest of the team members are to identify the team performance in general. We also encourage them to think about their productivity and efficiency and come up with ideas that could help themselves as well as the other team members.
-
[1] low Code Churn (ie: high-efficiency code, and the longer that code is providing business value)
-
[1] low amount of wasted time
-
[1] retrospective outcomes, build-measure-learn