I've got a new Azure DevOps extension published out to the Azure DevOps Marketplace.  This is the Wiki Age Report.  This came about as a need for a client that I have been working with.  They were looking for a way to keep track of potentially out-of-date documentation in their Azure DevOps wiki.  They wanted to see a report of the wiki pages that had not been updated in a long time, so that they could then assign work to the wiki page owners to go out and review it and make sure it is still correct and hasn't become out-of-date.  There's nothing worse than going out to the nice Wiki documentation in your project and finding that Wiki Page that tells you JUST what you needed to do, only to find that things have changed since that page was written.  Often we document process and procedures that shift over time because of our own changes, BUT we also might be documenting how to "Do that thing in Azure"  that we need to do.. and we all know how quickly Azure and the Azure Portal change... Now if that document was written a year ago, with screen shots and flows of how to accomplish something in Azure, chances are pretty strong that it's no longer correct.  These kinds of changes to documentation can come from all kinds of sources, so it can be important to plan to keep an eye on that documentation to make sure it's still correct.  

That's where this extension comes in.  You see it will show you a list of all the pages in your Wiki along with some information about when it was updated last.  You can choose your time threshold to see a quick visual Red-Orange-Green indication of what might be out of date.  

Now knowing what's "old" in your Wiki is a great step forward, but how about doing the work to review it and update it if necessary?  That's going to take some time, and probably needs to be accounted for in your team's planning activities... So this report will also let you create a new Work Item to assign and track that work.  This report will look at your project's configuration and figure out if you're using User Stories, or Product Backlog Items, or Requirements as your backlog requirement work item type and will create the work item for you.

Recently I've done some work with one of the amazing Agile Coaches we have at Polaris Solutions, Sara Caldwell, to come up with a tool to help her get some more work item state time data out of Azure DevOps.  The result is now, I've published a new Extension to Azure DevOps, focused on giving teams, scrum masters, agile coaches and whomever else might be interested, the ability to get a little more data on how their work items are progressing through their process, by measuring Flow Efficiency.  You can go read lots of things written by people smarter than me about how to apply Flow Efficiency and its benefits, but the short story is that it helps scrum and kanban teams get an idea of how work progresses from start to finish, with a focus on tracking the time things are being worked on vs. the time things are waiting and not actively being worked on.  This metric is an interesting thing to track because when teams are looking at things like Lead Time and how to improve that, focusing on the time work is "waiting" can help measure improvements a team makes.

Azure DevOps doesn't do a good job of reporting out how long work spends in different states or board columns, and that is the key for us to be able to measure Flow Efficiency.  So that's where this extension comes in.  It will look back in to the history of your Work Items and grab some of the data hiding within Azure DevOps and give it back to you.  Users can pick the team they want to work with, and the backlog level (stories, features, epics...) they are interested in.  From there we are able to see what work items have been closed (and are still closed) in a given timeframe, and figure out what board columns those work items have spent time in and how long on average things spend in those columns

Now we have some data about where work items spend time! Next to calculate flow efficiency, the user can categorize the board columns as either "Work" time or "Wait" time.  Once those categorizations are done, we can begin to get a sense of work vs. wait, as well as a Work Efficiency percentage.  Right now you can choose the date range you want to track for, and you can then use that to see improvements over time, the extension does not yet calculate the time slices necessary to trend things itself, so you would have to track that yourself.. but trending these numbers is next on my list of improvements, so if you install this now, you'll see some improvements to this as I get things done.

So that's out there in the Marketplace for you to add to your Azure DevOps instance! Hopefully it helps you and your team get more insights in to how things are working!

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!

Creating build definitions and release definitions in TFS and VSTS can become a real chore.  Have you ever wanted to give a build or a release a little bit more flexibility, so you can handle some situations based on a condition, but didn't have a great way to give the developers control of that without having to meddle with manually setting variables all the time?  

Maybe you wanted to handle creating an "alpha" or "beta" version build of a nuget package?  or perhaps you wanted a insert some control of how things deployed? Having variables to control these things is great, and can rescue you from having to clone your build and release to handle the various situations that you find yourself in.   BUT now you've just given yourself more variables to maintain, and more things to remember to set at build or release time. 

I've run into a few situations in some recent work where it just makes the most sense to give control of what happens when code is committed to the developers that own the code.  One of the most direct ways to handle some of those things can be accomplished by placing some of that variable information in the developers hands to begin with, and one of the easiest ways to do that is to give them some JSON to hold it.

Some of my current work is involving creating a deploy pipeline and workflow to help the various development teams to most easily deploy their code to the various "dev" environments that many of the teams use.  The development teams had set up a series of Web Application paths on the dev server to hold various instances of their applications, so that one team can deploy, without stepping on another team's workflow.  Now team A, can deploy to Dev server app space "F3" while team B can deploy to app space "F5" and they won't interfere with each other, and then later they can deploy to app space "Integration" and all play nicely together.  This is all great, except how can we easily get a team B to deploy over to Team A's app space without making sure they update all the right spots in the right release definitions?  Well, I suggested we find a way to standardize a "deploy" json file that could be used to control some of those things ... this isn't the first time I've had to utilize a json file in the source code to help customize the process flow of a build or release, so instead of trying to craft yet another one-off custom task, I decided to create a more flexible task that will read a JSON file and simply create Variables in the build and release for subsequent tasks to utilize.  This way, I can feed other tasks the information they need, and I never (hopefully) will have to write something to pull the data out of a JSON file for my build and release processes again.

Here's what I've got. It's in the Marketplace as "Json to Variable" and it will parse through a JSON file and generate variables with the data it finds.

So some JSON like this:

Gives me output like this, and I get four new Variables in the process for other tasks to consume

This just gives me one more tool to help make my build and release pipeline a bit more flexible.  The source code is in GitHub, and is written with Typescript to run as a node task in TFS and VSTS.   It handles JSON objects, and Arrays. Really, the goal of this is not to generate some super complex process, and a simple JSON should suffice for where I envision this working.  

For now, this will get me through some of the deploy and build versioning things that I'm working with the development teams on, and I think I will be able to use this in the future.  If you can use it, please pull it down out of the marketplace and give it a spin!