Your Kiro Health Checks

Ensure a healthier development workflow.

Before introducing your Kiro Health Checks, here's our philosophy.

We're well aware of the sometimes bad rap that health checks and metrics may get in an engineer context. We want you as an engineer to get value out of them, so that you can get better and improve. That's our aim, and always will be.

On the benchmarks below, we know every engineering team is different and no benchmark fits everyone equally. We took inspiration from our personal experience as engineers, and the 100+ engineers we spoke with in our 2+ years of research. We picked out those who we felt did a great job with their PR workflow, and decided on a good target to help you stay on track.

Over time, we'll build a stronger Kiro community benchmark system that you can draw on for your own personal workflow and team.

If you have any thoughts or feedback on how we can improve here, give us a shout.

On that note, here are the Health Checks you'll find on your PR Coach dashboard:

1. Number of open pull requests

  • The amount of open pull requests that are created by you and assigned to you as an individual engineer.

On the dashboard you'll have your current count, and then a targeted benchmark. Lower is better with this one.

Why it’s important to keep track of:

  • Based on the research from our personal experience and countless others, reducing your PR work-in-progress (WIP) to a small amount keeps your engineer workflow more efficient and focused. Also, it helps you stay on track alongside your team when delivering value to your customers. The 2 PRs benchmark may not fit every team setup, but it's here to help you stay vigilant so the WIP doesn't become to much to handle.

2. Pull request lifetime

  • The time between the oldest commit in the pull request to eventual merging of the pull request.

On the dashboard you'll have your current count, and then a targeted benchmark. Lower is better with this one.

Why it’s important to keep track of:

  • Another principle we believe in is seeking out customer feedback early and often throughout your development process. Getting feedback in production from your customers helps you and your team continue to grow and get better. After all, we're all here to deliver value to our customers. Again, we don't want the 1 day benchmark to be something that forces you to get stuff out the door for the sake of meeting the number (we don't advocate that, especially if it sacrifices quality and value), it's there to help you stay on track while keeping your customers in mind.

3. Average time in review

  • Time between assigning reviewers and all or any reviewer responding (approve/reject/ask for changes).

On the dashboard you'll have your current count, and then a targeted benchmark. Lower is better with this one.

Why it’s important to keep track of:

  • As highlighted in our Kiro Ethos, we want this to be a way to help improve the communication and collaborations with your teammates - in this case, it's around code reviews. You're all working together as a team to deliver value to customers, and we want to help you eliminate any bottlenecks or delays with code reviews. Similar to the pull request lifetime health check above, we don't want this to be a way to rush code review and sacrifice on quality. It's a way for you to keep tabs on it in case it steers you away from a healthy course.

If there’s something you can’t find in here, need some help, or have feedback, give us a shout at [email protected]. We're here to help in any way we can 🙏