Double Your Velocity Without Growing Your Team With RICE

 

SendGrid is focused on developing transactional APIs that our customers love and value. While we may have pioneered transactional APIs, we didn’t formalize the open source engineering team at SendGrid until June of 2015.

At that time, we didn’t have anyone dedicated to the open source libraries full time. The work had always been managed ad-hoc by our Developer Relations Team.

So our newly-structured Developer Experience Team jumped right in, put our heads down, and started working. We responded to pull requests, discussed topics on issues, and added some code. But the problem was that we felt like we were moving really slowly and didn’t feel like we were even making an impactful dent in what our developers needed. We had to find a way to work on the most important things—not just the things where people were yelling the loudest or that were the most interesting things to work on.

Needless to say, prioritizing what projects we work on and when has been a journey. So in this post, I want to share with you how we prioritize projects so we can continue to delight and provide value for our customers.

Prioritizing with RICE

We started out using Jira in the typical Agile way: Add a ticket for every single thing, prioritize them, make epics, and then start the sprint. We would start and, at either day one or day two, something important would come up from the community and we would need to rethink what’s in our sprints. It led to us flailing quite a bit, not knowing whether we should delay something two weeks or “just get it done and hope our sprint works out.” Spoiler: our sprints never worked out.

Around the same time, Intercom published an article about their prioritization framework called RICE.

Prioritizing with RICE has changed the Developer Experience team’s whole world.

I have to give a shout out to Intercom for coming up with a simple acronym and calculation, I can’t imagine how hard that was to refine and scale down all the things they wanted to include. RICE helps give you a score for every item in your list that then allows you to sort in descending order. Now you have an objective prioritization of the things you need to work on.

We found with our Jira board that it was very difficult, out of the box, to see true best-next items. We couldn’t objectively rank items inside our tickets without hacking into Jira, or opening the ticket for more information. Instinctively, once we had ranked everything, we started working from the item down our list in order to always have the biggest impact for our customers based on the data we had when we started on each task. Turns out we accidentally ended up turning our workflow to Kanban by using a solid prioritization strategy!

Bringing in Kanban and the backlog

One tenant of the Kanban process is to keep work in progress to a minimum. If you get more information about a really cool project it might go to the top moving forward. But if the “New Validated Project” already started and, even though it now has a lower score than the new hot project, the current project maintains our attention because 1) we are following Kanban and 2) the new project is in flight.

Rather than abandoning your new project that was at the top of your list when you started it and moving on to the new thing, finish it up, and then start the new project. This way you can focus, get it done, and then start something new.

Letting the backlog win

The need to stifle your desire to work on something really novel is arguably the hardest part of this process. We have had plenty of times where something really fun comes our way and we want to work on it right now, but we have something that’s in flight and that’s 10 items higher in the backlog. It’s important to realize that this might be a good time to look at your backlog and make sure you are being objective with your numbers.

It is always OK to question your own motives, or ask someone else to, in order to reevaluate and make sure that the numbers are as close to reality as possible. One way that we did this was to make “Reach” objectives based on usage numbers rather than gut-feel. Our guts, especially on fun projects, somehow always told us there were more people using a feature than our metrics actually indicated.

The results

Now you have the opportunity to level set with your coworkers about what you are working on and why. If they disagree, that’s great! You can use the RICE-calculated backlog as the baseline for your conversation about where this item is in the list and you can say with confidence that the top item is the next thing you’ll work on. “This thing is pretty low on the list, but it seems important, maybe we need more data?” Or maybe even “Oh, you’re right—that is a bigger problem that needs to be solved sooner!”

What happened for the Developer Experience Team

By employing this process on both our Open Source and our Documentation teams we were able to:

• Increase confidence in what we were working on
• Have better and more objective conversations about what’s next
• Double our velocity on Open Source work
• Added 50% velocity on documentation work
• Burn down our backlog more effectively
• Have a greater impact for our customers

Looking for more content on how to improve and grow your transactional API business? Join us at APIDays Transactional API conference July 12th in San Francisco! This event was created for startup founders, product managers, engineers, and marketers, and developers. Speakers and panels will consist of actual API practitioners and leaders sharing what they have learned along the way about the industry.

Photo via Visual hunt