Prioritizing Our DevRel Backlog with Form Builder, DMN, and a Process Model

Developer Relations teams typically have a wide variety of skills to meet community members where they are and help them get where they need to be. These skills can range from programming, creating content, and giving technical presentations, to mentoring community members on the best ways to use the product, running community programs, and communicating feedback to internal teams on ways to improve the product experience. But when the backlog grows faster than tasks can be completed, how do we prioritize the work that’s in front of us, ensuring we’re working on the most impactful items?

I recently faced this predicament on my own team here at Camunda. I needed to not only help my team decide which projects to prioritize but also help our coworkers understand how (and why) we respond to new requests.

While I could have written and published an internal strategy doc that listed our reasoning, information overload sets in quickly, and I’d rather not ask Camunda employees (Camundi) to read yet another page in our internal wiki every time they have a request. Instead, I turned to DMN and Camunda Platform 8’s new features to build a process model with an integrated form. While it’s not yet perfect, it’s already benefiting my team! How did I get here?

Step 1: Identify the criteria for prioritization

I chose to start with a DMN table, which would be the foundation of the model. Before I could build this table, however, I had to identify the criteria we would use to prioritize the DevRel team’s work. Many DevRel teams prioritize tasks based on impact on the developer community, alignment with the company’s goals, or level of effort.

In our case, the assumption is that the work being submitted to this form is independent of the projects we’ve already taken on as a team for the quarter. This allowed me to keep our criteria simple: alignment with the team goals and the urgency of the task.

Step 2: Create a decision table

With this criteria defined, it’s time to create the DMN table. These tables map the input values (timing and goals) to the output value (priority) based on a set of rules. A nice perk of building the prioritization rules into this table is that as our criteria change over time, I can update the table and the new rules will take effect immediately. Because the table is versioned, I can revert to a previous iteration at any time if necessary.

The first thing I had to define was the input data which the decision table will use to process requests. In my case, I used the following:

• Input: 2023 Goals
• Expression: goals
• Type: string
• Predefined Values: “healthy C8 community” “successful C8 community” “C8 community onboarding” “other”

Note: While filling in predefined values is optional, I found it helpful when populating the decision rules.

I set the second input (Timing) with fairly general ranges: this week, month, or quarter, and next week, month, or quarter, as well as no specific timeframe.

I kept the output value very straightforward: yes or no, with a possible exception that could be raised to me if necessary. Lastly, I’ve used the hit policy “first” in order to evaluate the rules from top to bottom and stop when a match is found.

The end result is a decision matrix that allows us to easily filter company requests that meet these specific goals and aren’t urgent (e.g. can be completed this month, next month, or next quarter). For anything that falls into the “this week” or “next week” timing, it’s likely going to be a no, unless it’s a very high-priority task that also aligns with our goals; in this case, the request is flagged as a possible exception in need of review. The outcome is a fairly straightforward model that outlines when we can prioritize requests and when we’ll need to either reconsider them at a later time or simply say no.

Step 3: Create a form to populate the decision table

I repurposed a simple Google form we’ve used for years, using the Camunda Form Builder so I could integrate it with my decision table.

Once the form was created, I made sure the key for the questions around the goals and the timing matched up with the expression in my DMN table.

Step 4: Integrate the form and decision table into a process model

An idea is submitted & evaluated

The next step was to create a process model using Web Modeler. This model represents the process of prioritizing tasks, including collecting the criteria via the form, applying the decision table to determine the priority of the task, and communicating the decision to the appropriate Camundi. Let’s take a look at the current model:

The first section of the model includes the completion of the form, the DMN table which helps us prioritize the task, and an automated Slack message (using our Slack Connector) that notifies the DevRel team a new request has been submitted.

I connected the form to the model by copying the JSON from the code editor in the form builder and pasting it into the properties panel of the user task “Complete DevRel Request Form.”

I then added a Business Rule task and connected it to the DMN table I created by associating the following fields:

• I copied the ID for the Decision from the Decision Requirements Diagram (DRD) view and pasted it in the Called Decision: Decision ID field for the Business Rule task.
• In the Result Variable field, I pasted the output name from my DMN table (abilityToHelp).

It was important to me to minimize blockers (including myself) for these requests and better enable my team to take action, so I wanted to make sure the entire team would be alerted whenever someone filled out the form. Using the Slack Connector, I set up an alert to go directly to our team channel.

The next iteration will include a link to the specific request, in addition to the results of the DMN table so it will be easy to see at a glance whether additional insight is needed.

The decision is validated

The next step in our process is to validate the decisions.

There are two decision gateways here:

• Do you need help making a decision? The DMN table will automatically determine this step, moving requests directly to Look at automated decision if the answer is a clear yes or no. If the answer from the DMN table is abilityToHelp = “possible exception,” it will be flagged and go the Escalate to Manager route.
• Do you agree with the decision? When I was first designing this process, our Community Manager Maria Alcantara made the excellent observation that there may be times when users disagree with the automated decision. If this is the case, requests should be escalated to the manager.

Right now, looking at the automated decision as well as making the decision are user tasks that have to be managed within Tasklist. If users need to escalate to manager in either case, they can type in a variable agree = false for the first question and doThing = false for the second. In the next iteration of this model, I’d like to have a Slack integration that allows us to say yes or no to both of these questions in order to move forward seamlessly.

The end result of all these decisions is that we have a clear path forward: we’re either going to tackle this project or not.

The outcome is communicated

Feedback loops are important to us at Camunda, so I wanted to make sure no matter what the decision was, there was a follow-up with the person who requested help.

Rather than listing every Camundi in the Requester DMN table, I chose to include variants of our team members’ names: first name and first + last name, in lowercase as well as camelcase, since DMN tables are case sensitive. The output is groupCamundi with either the value of devrelTeam or_ colleague._

These final tasks are all user tasks, but again, there are opportunities to include automation here:

• Create a Trello card in our task board based on the form.
• Send a refusal message to the individual who submitted the request.
• Notify the requester when the task is moved to the done column in our task board.

We could likely even turn the form into a Slack bot that then pings the appropriate team member. In short, there are all sorts of possible iterations here, which we’ll definitely explore as we roll this out company-wide.

Step 5: Be more productive

I have high hopes that this process model will continue to help us prioritize our work more effectively, ensuring we focus our efforts on the tasks that will have the greatest impact on our community members as well as Camunda company goals. Additionally, by streamlining the prioritization process, we are able to complete tasks more quickly and efficiently, improving our overall productivity.

While this prioritization of tasks might seem like a relatively small and perhaps insignificant issue compared to the other items on our plate, this DMN table, form, and process model will serve as the foundation for future team endeavors and resource-planning. Here’s to solving “mole hills” before they turn into mountains!

What have you created with Camunda lately? Let us know over in our forum. I’d love to hear how process models have made your day-to-day work easier!

The post Prioritizing Our DevRel Backlog with Form Builder, DMN, and a Process Model appeared first on Camunda.