Managing Sprint Interruptions with Slack Notifications

At Group Nine Media, our Tech and Product team is made up of many small, cross-functional teams (we call them “Pods”). Pods that have adopted the Scrum framework plan their work in two-week sprints to iteratively build and deliver their products.

Part of a Program Manager’s role at Group Nine is to act as a Scrum Master to the pods; coaching them in the ways of Agile development and continuously improving the teams. As a group, Program Management leverages learnings and insights from across all of our pods to paint a picture of how our entire Tech and Product system is operating as a whole. One common theme that Program Management noticed is that our Rate of Completion could be improved in several pods.

A low rate of completion can be attributed to many factors however, after looking into the data, one of the red flags that stood out was a pattern that demonstrated sprint scope being inflated with unplanned work throughout the two-week iteration. It was as if our team’s were attempting to hit a moving target every two weeks! We knew we could do a better job of coaching our teams about how to manage sprint interruptions.

The first step that we chose to take as a Program Management group was to be alerted when unplanned work entered an active sprint so that we could better manage each individual situation but Jira does not have a way of notifying us when a sprint’s scope gets changed. We decided to take matters into our own hands…

Goal

Improve the Rate of Completion of our teams sprints so that we can more accurately forecast our releases and be more confident in our commitments to stakeholders.

Hypothesis

Receiving automated notifications about sprint interruptions will ignite discussion amongst Program Managers that will result in minimal scope change throughout a sprint and in turn, will increase the probability that our team completes the work that we committed to. This will ladder-up into an improved Rate of Completion for our teams.

Experiment

Each time an issue is added to a current sprint, send a notification to the Program Management Slack channel so that we can coach our teams about how to handle the scope change.

Setting Up The Test

To get a notification in Slack each time someone adds an issue to an active sprint, we’ll need to do some coding to make the magic happen. We’re about to go deep into some technical stuff — skip to the “Results” portion of this post if coding doesn’t appeal to you.

This is the architecture that outlines how Slack notifications are generated and delivered:

Jira Webhook

The first step was to setup a webhook that sends a JSON payload to our custom Slack Notification Node.js app on Heroku whenever an issue gets updated. Our app will need to do the work of checking whether or not the issue was added to a current sprint.

Node.js App

We setup the Jira Webhook to POST JSON to a custom Node.js app running on Heroku. Let’s review some of the code that processes the Jira webhook payload. You can view all of the code for this app on GitHub.

Our app gets a JSON payload each time an issue in Jira is updated. When the JSON payload gets POST’ed to our app, we’ll do some processing to figure out if the issue’s sprint value has been changed. The payload comes with an object called “changelog” which includes information about each item that was updated in the issue. If the issue’s sprint value changed, we store the changelog value in an object called “sprintChanged” which holds information such as the previous value and the new value of the issue’s sprint.

We also declared another variable called “addedToActiveSprint” which calls a function that will check the status of the sprint that the issue was changed to and determine if that sprint is active, closed, or planned for the future. We pass it a list of sprints that the issue belongs to.

customfield_10016 is an array of strings that contains information about the sprints that the issue belongs to. One of the attributes of a sprint is called “state” with possible values of “CLOSED”, “ACTIVE”, or “FUTURE.”

The sprintChangedToActiveSprint loops through the array of strings (representing sprints) and checks if any of the sprints have an have attribute where the state is active. As soon as an active sprint is found, the function returns true. If none of the sprints are active (or if there are no sprints at all), the function returns false.

Next, the app will use the information we gathered about the issue’s sprints to determine if a notification should be sent or if the webhook’s payload can be ignored.

If there is no change to the issue’s sprint value, we can ignore the webhook’s payload because we only care about changes to the issue’s sprint. Removing an issue from the sprint is an action that we chose to ignore for our Slack notifications because our struggles have been related to the increase of scope during iterations, not the removal of issues. Additionally, we don’t care if the issue was added to a future sprint — our Product Managers can go ahead and plan away!

I truncated the postData object in the code above to save space. It is just the body of our POST request to Slack that includes the necessary formatting for our Slack message.

Slack Integration

On Slack’s side, we setup an Incoming Webhook — this is a feature that will allow Slack to digest payloads from our custom Node.js app and post messages into Slack channels. It is in this configuration where we choose the channel to post our message about changes in the sprint. The Webhook URL is the URL we use to POST to Slack in our Node.js app. We can also choose the name and logo to be used when sending messages in Slack.

That’s it! Now, each time an issue is added to an active sprint, our Slack channel gets an automated message that we use as a cue to have a conversation about the scope creep.

Results

We have achieved positive results since implementing the Slack notifications…

We can’t attribute the amazing results to this experiment alone. Each sprint ends with a retrospective where each pod formulates new experiments to improve the way they work as a team. However, it is worth noting that since we’ve been more aware of changes to our sprints, we’ve been able to manage those changes more effectively and our Rate of Completion is better now than ever before!

Our Program Management team is always finding new ways to help improve our teams — be on the look out for more posts on similar topics.

To use this integration for your team, go to this GitHub page and follow the steps to get started!