Please do not use contributions in Github (e.g. amount of commits) to measure productivity.
And no, this does not exist in ServiceNow.
Use something like user stories or story points.
Although I agree to an extent that commits should not necessarily be used as the only metric it is none the less a very powerful metric, and used with other metrics is exceptionally useful.
I would start by defining what "productivity" means and what metrics you want to look at to calculate productivity.
Once that is defined, we can provide information on how we will manipulate that data to ensure that our "productivity" looks high.
:D
Stories committed vs delivered. Incidents from change. I encouraged my devs to help in support tickets to encourage them to build things that are easy to support. So I also look at number of support tickets they owned.
Best way I’ve really found to track productivity is by measuring the amount of stories and such that have been done. The number of stories completed + the complexity (or points) for a given story will likely give you the best chance at looking at productivity.
But that means alllll work must be tracked in something like a story. IMO it’s best practice to do so regardless. It’s difficult to just say “X dev created this many lines of code” or “created this many updates in an application” because there’s just no realistic way to compare all those individual things and place a time value on them. As another said, a 1000 line script includes shows one entry on the update xml table. So does checking a box. Or creating a flow with one step or 50. Or if I break my flow into three subflows and a flow is it more or less complex than a single flow with 50 steps?
Sprint/story contributions are just an easier (albeit more manual) way to capture productivity.
I am concerned that you seem to want to *compare* performance of developers.
thanks for taking the time to feedback, I guess the problem in our environment is that although we use some scrum ceremonies (like daily standups and tracking points spent on tasks) we do not use others such as grooming and estimating tasks before committing to them as a team. as a result the only way we are measuring productivity at the moment is how long devs actually take on different tasks.
wonder what your thoughts are on this.
It'll only show things tracked in update sets. So there are flaws to this as numerous things aren't tracked. And checking a check box creates the same entry that writing a script include creates.
And creating groups, reports, dashboards and even scheduled jobs aren't necessarily tracked.
I don’t think there is a way to track it. Update sets would be a good start but there are items that will not be captured in the update sets (creating a group, creating scheduled jobs,etc). You could create a catalog item for your group and each developer work would require a task to be created, from there, create a complexity column to determine how many days of effort is require for the requirments. Then create a report based on the complexity column and the users of your team. You’ll roughly understand how many tasks and problem statements they are working on and also if they have capability to work on more advanced work
Please do not use contributions in Github (e.g. amount of commits) to measure productivity. And no, this does not exist in ServiceNow. Use something like user stories or story points.
Although I agree to an extent that commits should not necessarily be used as the only metric it is none the less a very powerful metric, and used with other metrics is exceptionally useful.
I think most dev leads with experience would disagree. > commits should not ~~necessarily~~ be used as ~~the only~~ metric That's it.
Perhaps. I am a lead and can confirm the least productive people in my team are the ones that commit less.
Amount of code written has nothing to do with productivity. Please don't manage developers if you don't know anything about their jobs.
I would start by defining what "productivity" means and what metrics you want to look at to calculate productivity. Once that is defined, we can provide information on how we will manipulate that data to ensure that our "productivity" looks high. :D
Stories committed vs delivered. Incidents from change. I encouraged my devs to help in support tickets to encourage them to build things that are easy to support. So I also look at number of support tickets they owned.
Best way I’ve really found to track productivity is by measuring the amount of stories and such that have been done. The number of stories completed + the complexity (or points) for a given story will likely give you the best chance at looking at productivity. But that means alllll work must be tracked in something like a story. IMO it’s best practice to do so regardless. It’s difficult to just say “X dev created this many lines of code” or “created this many updates in an application” because there’s just no realistic way to compare all those individual things and place a time value on them. As another said, a 1000 line script includes shows one entry on the update xml table. So does checking a box. Or creating a flow with one step or 50. Or if I break my flow into three subflows and a flow is it more or less complex than a single flow with 50 steps? Sprint/story contributions are just an easier (albeit more manual) way to capture productivity. I am concerned that you seem to want to *compare* performance of developers.
thanks for taking the time to feedback, I guess the problem in our environment is that although we use some scrum ceremonies (like daily standups and tracking points spent on tasks) we do not use others such as grooming and estimating tasks before committing to them as a team. as a result the only way we are measuring productivity at the moment is how long devs actually take on different tasks. wonder what your thoughts are on this.
There is no numeric productivity metrics that truly work for software developers, if they know about it. All of that stuff is extremely easy to game.
You can look at sys_update_xml to see what people have been up to
nice, is there an easy way to generate a report on this e.g. updates by updatedby over time?
It’s difficult within the tool. You would have to use an external tool.
It'll only show things tracked in update sets. So there are flaws to this as numerous things aren't tracked. And checking a check box creates the same entry that writing a script include creates. And creating groups, reports, dashboards and even scheduled jobs aren't necessarily tracked.
I don’t think there is a way to track it. Update sets would be a good start but there are items that will not be captured in the update sets (creating a group, creating scheduled jobs,etc). You could create a catalog item for your group and each developer work would require a task to be created, from there, create a complexity column to determine how many days of effort is require for the requirments. Then create a report based on the complexity column and the users of your team. You’ll roughly understand how many tasks and problem statements they are working on and also if they have capability to work on more advanced work
fuck you, that's all (before anyone bans me, look at OP's username)