A review of Azure DevOps Boards, from an APEX development perspective

I was recently asked to review a number of elements of Microsoft’s Azure DevOps suite, to consider how beneficial they may be for an APEX development team such as mine.

One of the first features I investigated was Boards. Although I’m looking at this from the perspective of an APEX developer, I imagine a fair bit of my findings are pretty generic to a wide range of development technologies.

To set the scene, my team here at Explorer UK work on projects which vary greatly in size and scope. Sometimes there might be just one developer working on something for 6 weeks or so, working directly with our client to plan and deploy (e.g. creating a small, stand-alone administration app). Other times there might be 6-7 of us working on 12-18 month project, working with our team of PMs (e.g. a large Oracle Forms to APEX conversion).

Azure Devops Boards

The question I wanted to consider was: “does Azure Devops Boards provide enough functionality to allow us to manage one or both of these types of projects, as well as everything in between?”

One thing I really like about boards is how I can use it for ‘snagging’. When developing in APEX, as I approach the end of a page or module, I like to keep lists of things to fix or check. These are the kind of things that I may notice when I’m developing or testing something else, I don’t want to drop what I’m doing and fix it right then, and I don’t want to forget it either. It might be an obvious bug or it might just be a question or something to check. My current approach is just to track this in a basic spreadsheet or txt doc. I like the function to create bugs in boards because a) it’s very quick and b) it’s clearly separable from other different types of task, such as user stories. Boards provides a few different views of work items. You can split bugs, user stories, epics etc. up how you like and actually use different views to work through them.

Kanban style view

Work Item view (filtered for bugs and tasks only)

A problem I’ve seen in JIRA and Trello is that when there lots of ‘little’ things to record, you either have to create many items at the top level, potentially obscuring the user stories or larger tasks, or you add them to a single card or ticket, in which case it can be pretty hard to see progress. By allowing you to split bugs and user stories into different areas, you can keep your high level view, and then switch over to your bugs and snags. Also, the ability to either just create a ‘1 liner’ bug or work item really quickly, or enter more detail, allows you a lot of flexibility.

Another plus point is the integration with the test plan module. You can directly generate test plans based on the work items you create. As with most things in this suite of functionality, you can make this as simple or detailed as you like – from a 1 line check to an in-depth end-to-end test. I would argue that for smaller projects where you are ticking off tasks in a less formal fashion, the integration with test plans is perhaps a little unnecessary because you can probably achieve what you want to from board alone. However, on a large project it is invaluable to be able to integrate your user stories and test runs.

On larger projects, you can begin to use the resource planning functionality to its fullest, although there may need to be a fair degree of upfront training and set up to fully make use of these features. A good grounding in Agile methodology is definitely required here. Management of work items within sprints can be enhanced by managing things like holidays and utilising burn-down charts to review efficiency and refactor estimates.

Conclusion

Ultimately, I can definitely see a lot of mileage in using Azure Devops boards to deliver APEX projects going forwards. The flexibility provided, and the potential for integration with testing, repos, pipelines etc. mean that both simple and complex projects can be catered for. The key factor is identifying the level of detail needed for each project, to ensure that the overhead required to manage the chosen features provides the maximum benefit to the project for the minimum cost.

Author: Michael Pickering

Job Title: Oracle Development Consultant

Bio: Michael is a Development Consultant at DSP-Explorer. Having attained an MSc in Computer Based Information Systems, he began his career developing health-care reporting solutions, before moving to specialise in Oracle Forms and Reports in the construction industry. Here at DSP-Explorer he is part of a highly skilled development team providing APEX development solutions and training to both UK and international businesses.