Haystack aggregates activity in git to give engineering managers more visibility into how their team's work. We came up with the idea when we realized how difficult it is to answer a simple question: 'Is the team doing better than we were 6 months ago?'. We realized how hard it is to not only visualize trends on their team but get actionable insights into the biggest areas to improve. Whether it's spending too much time in code review, taking on too much concurrent work, or even getting bogged down with technical debt; we wanted a tool that can not only help to spot issues but also alert us so we can take action. Introducing Haystack.
In the book you can check the sections Avoid Burnout: Work Overload and Overload Risk: Too Much Concurrent Work.
We get 6 months weekly average pull request throughput of each team. We call this the "Baseline Throghput". If a team has more (or less in some cases) pull requests open than the baseline, we consider that a "too many".
Too many Open Pull Requests can signal taking on too much work, scope creep, change in priorities and unexpected issues/bugs coming into the sprint. It’s good to keep an eye out of the number of Open Pull Requests since it’s a great indicator of the team’s current workload.
Comments
Haystack aggregates activity in git to give engineering managers more visibility into how their team's work. We came up with the idea when we realized how difficult it is to answer a simple question: 'Is the team doing better than we were 6 months ago?'. We realized how hard it is to not only visualize trends on their team but get actionable insights into the biggest areas to improve. Whether it's spending too much time in code review, taking on too much concurrent work, or even getting bogged down with technical debt; we wanted a tool that can not only help to spot issues but also alert us so we can take action. Introducing Haystack.
Very curious now: how do you know what is "too much" time in code review?
Could you provide an example of actionable insight you provide when you have detected that a team is taking on too much concurrent work?
In the book you can check the sections Avoid Burnout: Work Overload and Overload Risk: Too Much Concurrent Work.
We get 6 months weekly average pull request throughput of each team. We call this the "Baseline Throghput". If a team has more (or less in some cases) pull requests open than the baseline, we consider that a "too many".
Too many Open Pull Requests can signal taking on too much work, scope creep, change in priorities and unexpected issues/bugs coming into the sprint. It’s good to keep an eye out of the number of Open Pull Requests since it’s a great indicator of the team’s current workload.
Absolutely agreed. None of that is particularly actionable, though. "Don't do the bad thing" is not actionable advice!