Future metrics

On this site, you will see an overview of the metrics that are interesting for our project. The ideas for the metrics stem from our dataset with action points of scrum team retros.

German table

German version

Action Point aus Datensatz	Metrik	Erklärung	Machbarkeit	Nach Sprints unterteilen?	Nach Teams unterteilen?
Zu große Reviews, "PR's zu groß", "PRs shouldn't get too big"	PR Diff size	Man betrachtet die größte der PR Diffs über die Sprints hinweg	aufwendig, aber über api alle PRs holen und für jeden die pull requests files, die additions und deletions beinhalten	✅	✅
"Pull Requests bereits vor Sprintende", "zu wenig zeit für tests, reviews, ... eingeplant", "mehr Zeit fürs Review einplanen"	PR creation Heatmap	zeitpunkte der Pull Requeste in einer Heatmap dargestellt	einfach machbar, mit der pr creation date	✅	✅
pair programming rotieren	co-authoring rotation/team rotation	Prüfen der roationen der authoring tupel	tricky. Tupel aus co-author und commiter erstellen. Bekommt man hier über commit.author und commit.message	✅	✅
Blockierung durch warten auf Feedback	PR first review response time/pull request stale time	es wird betrachtet, wie lange es dauert bis das erste Review für einen geöffneten PR gemacht wird	machbar, einfach hier alle reviews chronologisch holen und submitted_at betrachten	✅	✅
issues should be supplied quickly by contacting the PO so that idle time of the developers is at a minimum"	idle-time of a team	issue score nur für prs
	stale time of an issue
pull request bilder hinzufügen	pr score	issue score nur für prs	machbar, über das body tag hier	✅	✅
CI red for a while due to carthage	CI red times?	check wether github checks are red on dev branch	zu viele inkonsistenten Variablen, dev branch, welcher workflow etc. Wäre aber machbar über das -> 🚫 wegen zuvälligen variablen und Abhängigkeiten
poor acceptance criteria leading to stories getting accepted that don't actually work		🚫
git commit messages	commit message score	analysieren der commit messages auf syntax, länge und wort inhalte	🚫	✅
beware knowledge silos	wiki quality	überprüfen der qualität des wikis anhand von seiten und länge und updatehäufigkeit	🚫	✅
feste Arbeitszeiten, "keine festen officezeiten", "working weekends"	commit heatmap		done	✅	✅, wenn machbar
issues klein halten	issue size		done	✅	✅
reviewaufwand unterschätzt	pr closing times		done

English table

English version

Action Point from dataset	Metric	Explanation	Feasibility	Break down by sprints?	Subdivide by Teams?
Too big reviews, "PR's too big", "PRs shouldn't get too big"	PR Diff size	Look at the biggest of the PR diffs across sprints	effortful, but get all PRs via api and for each get the pull requests files, which include additions and deletions	✅	✅
"pull requests already before end of sprint", "too little time for tests, reviews, ... scheduled", "schedule more time for review"	PR creation heatmap	timing of pull requests shown in a heatmap	easy to do, with the pr creation date	✅	✅
pair programming rotation	co-authoring rotation/team rotation	checking the rotations of the authoring tuples	tricky. Create tuples from co-author and commiter. Get here via commit.author and commit.message	✅	✅
blocking by waiting for feedback	PR first review response time/pull request stale time	it looks at how long it takes to do the first review for an open PR	doable, just get here all reviews chronologically and look at submitted_at	✅	✅
issues should be supplied quickly by contacting the PO so that idle time of the developers is at a minimum"	idle-time of a team	issue score only for prs
	stale time of an issue
pull request add images	pr score	issue score only for prs	feasible, via the body tag here	✅	✅
CI red for a while due to carthage	CI red times?	check wether github checks are red on dev branch	too many inconsistent variables, dev branch, which workflow etc. But would be feasible via the -> 🚫 because of too many variables and dependencies
poor acceptance criteria leading to stories getting accepted that don't actually work		🚫
git commit messages	commit message score	analyze commit messages for syntax, length and word content	🚫	✅
beware knowledge silos	wiki quality	check the quality of the wiki by pages and length and update frequency	🚫	✅
fixed working hours, "no fixed office hours", "working weekends"	commit heatmap		done	✅	✅, if feasible
keep issues small	issue size		done	✅	✅
review effort underestimated	pr closing times	done