I've published a new Azure DevOps extension to the Marketplace called the Pull Request Completion Report.  This extension will add a new Hub to your Repos section.  It is designed to give you a little insight in to the Pull Request process on your repo. It reports stats on completed Pull Requests so you can answer a few questions maybe you weren't clear about before. 

How Long does it Take a Pull Request to get completed?

This report shows you the average time a pull request takes to go from created to completed.  This metric is interesting on a couple sides.  If you see the average time is really short, something in minutes maybe, then you may start to question, are your PR Reviewers actually doing a review? What are they doing to approve this Pull Request? Are they just rubber-stamping things?  On the flip-side, if the average time is really long, something in days maybe, then you may start to question if your PR process and reviews are acting as a bottleneck in your team, slowing their velocity.   Either way, this helps give you a little insight in to how this repository is going.

What Branches are Pull Requests happening for?

Depending on your branching strategy this report will give you a little vision in to how your team is working with those branches.  So if you're following a gitflow branching strategy you'd likely expect a larger number of Pull Requests against your Develop branch.  So what really is the Ratio of PRs to Develop vs. Master? How many updates are you generally doing before you release something?  

This graph will group branches in folders for you, so if you're organizing your branches in to things like "release" and "hotfix" you can start to see just how many bug-fix PRs are happening against your release branches in general.  Does this repository have a much higher number of those types of PRs versus other repositories? Do we never PR bug fixes in to our release? Is this repository only ever following a Pull Request process on code to the master branch? Any of those behaviors are fine and may be the process you intend, but this chart will start to confirm that that behavior is actually what your team is following.

Who is approving all of the Pull Requests?

Ever want to see who is doing all of your pull request reviews? Or want to see how many Pull Requests are being completed without a Pull Request approver assigned? Do you have a couple of lead developers charged with doing the bulk of your reviews? Are they actually doing them? Are they overloaded? is your team taking time and doing peer reviews? are things spread out as you expect? This report helps you see what's happening, who's doing the reviews, and how many are going through without a review. This can help get a quick insight in to that activity.

How are your optional reviewers being used?

This report will graph out the review stats for the people assigned to your Pull Requests.  If you had optional reviewers added, are they all given time to review things? Is the team moving forward without all the reviews? Or are you adding too many optional reviewers? This chart will show how the approvals are going.  If you start to see large trends in "Did Not Vote" maybe you start asking about why PRs are being completed without giving everyone time to review, or maybe you ask if your team is adding people un-necessarily? However this is going on your repo, you now how some stats to start looking in to how the team is dealing with Pull Request reviews, and how you might improve either the quality of the reviews, or the quantity of things your team is asking of each other. 

Are the Groups you expect to review things getting to their reviews?

If you have some groups or teams assigned as your reviewers, you may want to get a view of if those teams are doing their reviews.  This report is like the individual report, above, but now at the Team or Group level.  So if your Pull Request process assigned groups, either required or optional, to your Pull Request, now you can see what's happening there.  Are the Optional groups reviewing things? How often? At my client, we have assigned the Application Security team as a optional reviewer to all the Pull Requests, but that team started wanting to see how many reviews they actually participated in, they didn't really have any good idea of that before, but with this chart they will be able to see just how many they were a part of.

So that's it, that's the new extension.  I hope you see some value there, I hope maybe this can help answer questions and give you a little insight in to how the team is dealing with code.  I think that there is some good power in the data, it may confirm that your team is doing the things you expect, and that's great to have the power to confirm.  Or it may start to give you some ideas on where you can tweak your process to give you some better outcomes.  Hope you find it useful.

At my current client, I have been working with a Scrum Master who has begun working with an established team who has been working with a Physical Kanban board using Post-it Notes on a white board to track their work. This has been working well for them, and so the Scrum Master doesn't want to disrupt their process. However, there is a need to track that work inside TFS/Azure DevOps.   We wanted to enter the work items in Azure DevOps, and we were even able to replicate their physical board inside Azure DevOps boards pretty faithfully.  But that big physical board is still a great way to view what's happening, and the team wants to keep using it.  SO I was asked if we could print out "Cards" for those work items so that they can be used to put up on the physical board... Now, there was no good out-of-the box solution.. and going through the Marketplace led to one promising extension name "Pretty Cards" that promised to enable printing of cards... However we found that the work-item support in that extension was lacking, and the fields and card layout that that extension is using were not really quite what we were looking for.   I went to the github repo for that extension to see see if I could request changes or what they were doing with Pull Requests.  I found that there were other people submitting similar requests to what I would submit and they had not gotten any responses in close to a year, and there were also old Pull Requests that were not getting anywhere, so I felt that that repository was pretty dead.  

So I had a need, and I had a dead extension that was "close"... So my next-best course of action was to fork that repository and make the changes I needed! So I have published a new Azure DevOps extension to the Marketplace to enable users to Print Kanban-style cards for their Work Items. The Extension can be found here Print Physical Cards 

This extension improves upon Pretty Cards in that it will print any Work Item type; Pretty card could only print User Story, Task, or Bug, which left people who were not using Agile process template high and dry.  My new extension also prints out a more consistent set of fields. I include things like Title, Assigned To, and estimate value (Story Points are used for User Stories, Business Value used for things like Feature and Epic, Original Estimate value used for Tasks etc..). Also supported are printing Tags, which was something we really can use as Tags are leveraged on Work Items here.  You can also multi-select work items and print multiple cards at once! It fits three cards to a page, and will page break appropriately so you shouldn't get any cards split across pages.. 

Here is an example output of some cards that I selected to print:

So! That's my story, hope there is some good value here for somebody who wants to still use a Physical Board, but still track their Work Items inside Azure DevOps!