One of my favorite things about working at Root16 is that I now get to be super hands-on with clients and projects once again – admittedly, I gravitated away from these areas over the years, and really appreciate the opportunity to get back into the day to day details, managing projects for our clients.
Fortunately, getting back into day to day project management has been much like riding a bike, it was a little awkward at first but came right back to me in pretty short order. Now that I’ve settled in, I’m taking a look at this ‘new bike’ I’m riding and have noticed it has a pretty cool new feature in using Azure Dev Ops (ADO) to help us manage manage our projects more efficiently. Historically, I’ve always used either a homegrown CRM to do this, or a customer instance of JIRA or the like.
Lately, we’ve started relying on ADO more as it is better suited for our agile development methodology when compared to traditional documentation. As we’ve become more familiar with ADO, we’ve found new ways to take advantage of some key features that allow us to streamline and normalize our process around things like User Stories, Tasks, and Bugs – tailoring ADO Templates, specifically for our D365 needs.
For example, just about any D365 implementation will consist of business requirements that result in the creation of Dataverse Tables for the build-out of the overall application data model. By using ADO templates, we now have a standardized tool to capture these types of business requirements. Using this new tool results in fewer requirement gaps and reduces the necessary follow-ups required for clarity (I.e. time and money). By standardizing these templates for a given type of artifact, we normalize the input and creation process – resulting in a complete requirement from the get-go, or at minimum, a crystal clear view of what we’re missing so we can track that down. We’ve also found that these templates are extremely helpful for new hires, as it gives them an understanding of the types of questions to ask to vet a client’s business requirement fully.
Below, I’ll walk you through setting one up using the ‘capture’ functionality. You can also create templates from the Project Settings > Team Configuration > Templates, but my lack of efficient HTML coding skills found the ‘capture’ functionality A LOT easier to work with. For the example below, I’ll create an ADO template to support the creation of a new Table within D365.
First, start by creating a brand new, blank, Task within ADO.
Once you have a new Task, build it out as if it were the template starting point you’d want for future Tasks.
***For details with a binary response (‘Yes/No’ answers), I started also providing those inputs as options to ease the burden of data entry and provide guidance on the type of input required.
Once you have the Task formatted in a way that makes sense and allows for easy data entry, you select ‘…‘ > Templates > Capture. This will take a snapshot of the HTML you have defined for this task and create a template for you to review.
At this point, you’ll be asked to name your template, define which Team it should be applied to, and which of the components you’ve defined should be included within the template – for this example, I am not concerned with things like Area ID, Assigned To, Iteration ID, etc. – for our use case these fields should not be uniform across all Tasks created so I remove them by clicking on the red ‘X’ next to each. Nothing you set here is permanent; you can go back into the template once it’s created to make any necessary adjustments.
Now that you have created and saved your template, it will be available to all Users on the defined Team to use. They can access the template directly within a task by navigating to ‘…’ > Templates > [Template Name].
The benefits have been plentiful, but as with most things, there are a few pitfalls or gotchas we’ve stumbled across along the way to be aware of:
- These templates are Team specific, meaning they do not travel well across Teams or other ADO instances, so we need to recreate these for each instance – in most cases, we simply copy and paste the HTML, so not a huge effort, but still annoying.
- Table support isn’t great within ADO, so we have left our layout fairly basic – if/when our development team slows down, we’ll probably have someone smarter than me mess around with the HTML to see if there are ways we can generate a better UI for data entry.
- Editing the HTML of a template once it’s been captured is not ideal, as you’re only provided a small window to make the edits in – when this has been required, we’ve been copying/pasting the HTML into an HTML editor to make our edits, as it is A LOT easier than using the small field provided.
So far, this has been a huge win for us – it’s removed several barriers of entry for the creation of streamlined business requirements, standardized our process across our organization, normalized our project requirement data, and provides ongoing training and direction for new hires as we grow.