Business Intelligence projects are rarely linear. – Prof. Dr. Rowland Dax
In general, BI projects consist of multiple components that need to be designed, created, and delivered simultaneously: data extraction, data modeling, DAX calculations, report design, data validation, and user testing, etc. Each of these streams depends on the other, and the process is mostly (if I said almost never, I wouldn’t be exaggerating 🙂 ) unpredictable.
When there is no central planning, very quickly you start seeing things like this:
- Chaos begins. Requests stay buried in emails, Excel files, chat messages, or someone’s notebook.
- Transparency disappears. Nobody can clearly answer the question, “What is done, what is pending?”
- Disorder becomes a thing. For example, ETL packages are ready but not scheduled; data is loaded but the cube has not been processed.
- Priorities get blurred and clash. Every stakeholder pushes their own request, and suddenly everything becomes urgent.
- The test process turns into chaos. Bugs and feedback vanish in meetings or emails, and the same issues resurface again and again.
- Traceability is gone. Looking back, it’s hard to know what was delivered, how long it took, or who was involved.
This is where a Board comes in. It’s not a magic wand of course, but at least it makes things visible, shows who’s working on what, and brings some order. In short, it doesn’t solve the complexity, but it gives that complexity some structure and visibility.
That’s why I went down the rabbit hole and started thinking about how a Board should be set up for BI projects, and began digging into the topic.
By the way, the choice of Board was easy for me (I mean, if you live in the Microsoft ecosystem and there’s a product that comes for free, why not 🙂 ), so I went with Azure DevOps Boards.
The first thing I realized during this process was that I didn’t really know how to structure Azure DevOps Boards for BI projects. Naturally, I started researching online. With the advantage of already being familiar with Agile and Scrum, and having used similar Boards in previous software projects, I dove into the journey with some confidence… but quickly hit some walls. Because you can’t really find a solid example online of how to configure Azure DevOps Boards specifically for BI projects. Sure, there are plenty of examples out there, but most of them are tailored for software projects. Software projects are one world, BI projects are another. They may look similar at first glance, but the outputs are different, and so is the way you track the work.
That’s exactly why I started bending and tweaking Azure DevOps Boards in my own projects to make it fit better into the BI world. In the following parts, I’ll share that journey and my setup. Hopefully, it will be useful for you too.
First, let’s go into the Organization settings and open the Boards section. The Process section in Azure DevOps Boards is essentially the template that defines how your teams will work. You can either use the out-of-the-box ones like Agile or Scrum, or you can create your own custom process and link your teams to it. This choice determines which work items (User Story, Task, Bug, etc.) you’ll see, which steps they’ll go through, and how they’ll appear on screen. In short, this is the foundation of your project’s work tracking system.
Boards offer four main processes: Basic, the simplest option for those who just want straightforward task tracking and not-too-complex projects. Agile, the most commonly used template by software teams; you move along smoothly with User Stories, Bugs, and Tasks. Scrum, perfect for teams that embrace sprint and backlog concepts. And CMMI, for more corporate, formal projects that require detailed process steps. If you’re not sure which one to pick, go with Agile, since that’s the one I’ll be covering 🙂
The first step is to click “Create inherited Process” to create a customized version of one of the existing processes. Microsoft doesn’t let you change the main processes directly, nor add entirely new ones. You can only base your custom process on one of the existing ones.
When you click into the newly created process, you’ll see the main Work Item Types used in the Agile process listed.
There are also two other tabs: one where you can view and adjust Backlog Levels, and another showing which projects are using this process.
In my next blog post, I’ll go into detail on these elements one by one with examples.
The topics will be:
- Work Item Types (WIT)
- Which BI project components WITs correspond to
- Backlog Levels and their meaning