How to Handle Bugs, Backlog, Prioritization and Communication with the Burndown Framework
In two previous posts, I introduced how we crafted our own framework for building product at Drift (Burndown) and talked through how you can actually implement the Burndown Framework at your own company in my second post.
Now, it’s time to talk about the things that sometimes feel secondary to the process, which are actually key to making all of this stuff flow properly. Those things are…
- Dealing with bugs
- Handling your product backlog
- Choosing what to prioritize next
- A weekly cadence of fully transparent updates
1 — Dealing with bugs
We believe bugs should be entirely owned by the engineering team. As thus, Github issues are where they live. When bugs pop up, anybody on the team can create a Github issue. If it’s a customer-reported bug, we give it a red “Bug” label in Github and post a link to the conversation where it was reported. We prioritize these bugs over others.
As a general rule of thumb, we’re spending about 20% of our time tackling bugs, and the other 80% on new features, infrastructure work, and improvements to existing features.
As bugs surface, it’s up to the engineer’s discretion which need immediate attention and which can hold off for a bit. This is why the “Bug” label in Github is so important because it increases visibility and urgency into the fact that it’s happening for a paying customer, which could result in churn if the bug is critical.
While we were implementing Burndown, for the first few months, once a week, the product manager on each team would sit down with the tech lead and go through the backlog of bugs in the Github repos that their team owns. This way, the PM and the engineers could get aligned on what was most important, why, and learn to trust each other’s judgement over time.
As the Burndown principles and framework became more a piece of the culture, and as the PM would trust the engineers to make the same calls they would, that meeting was no longer necessary on a weekly basis. Now, at the start of each week (usually over the weekend) the tech lead and engineers will go through the Github issues and pick out the top most important bugs they plan to tackle that week.
Since Burndown doesn’t operate in hard week-long cycles, there are consistently bugs that are introduced that require us to halt what we’re doing and tackle right away, so we make sure leave extra capacity to handle those as they come up so they can be worked on in parallel.
2 — Managing your product backlog
By now you might be wondering…what do you do about your backlog that has ideas for 4, 6, and 12 months out? Where do keep all of that information and keep it organized?
Depending on the size of your backlog, the Trello board you use to implement the Burndown framework may begin to break from too many lists on the far right of the board, which is completely fine. That’s what happened to us. So we evolved.
Now, we use the main product Trello board only as a place where we scope and document microsprints that will actually get done. If something’s been in there for over a month and keeps getting pushed around and never done, that means it’s not top priority and likely will never be. So we archive that list.
The Burndown framework is designed to keep you focused on what’s in the short and near term around the highest-leverage stuff you can be doing. Anything designed and scoped that’s 3+ months out, unless you’re a larger, extremely structured organization, is often going to change drastically by the time you reach that time anyway. We’ve had a designer on one of our teams get 3+ months ahead of the team and ultimately most of what she designed never made it to the light of day because we learned quickly that we wanted to take things in another direction. And that’s okay. That’s what we sign up for using Burndown. The worst case scenario there would have been to continue implementing those designs simply because they were already done. Since Burndown is inherently flexible, it allowed us to easily say no and take a different course that had more promise.
If you’re like me and are customer-development focused, you still need a place to organize all of the customer feedback you get on a weekly, and daily basis. I’d suggest either making a different Trello board to hold all of these ideas and pieces of feedback or keep expanding the width of your Trello board indefinitely so long as you go through and gut-check it every few weeks and archive things that are not aligned with where the product is going.
3 — Choosing what to prioritize next
The best way to determine what the next most important list to tackle is to ask yourself this…
“What is the one thing that provides the most value to our customers and aligns with our business goals and focuses?”
Answering this question should provide you with the thing that will give you the most leverage in the long-term to continue adding value to your customers. The question is a derivative of the question that Gary Keller poses in his book, The One Thing, which is “What’s the one thing I can do right now to make everything else easier or unnecessary?” We’re big fans of this philosophy at Drift as we believe it helps us focus on the right things.
We also thematically structure the upcoming priorities of the company, which we put into a single slide or list and repeat it over and over again to the team. In our case, an example list would look something like this…
- Keeping the product stable
- Driving more signups
- Increasing the activation rate
- Innovating our chat widget
This gives us all a guideline to reference when we’re asking ourselves what we could be focusing on next. If you can’t do something that directly benefits #1, then work on something that impacts #2, etc.
4 — A weekly cadence of fully transparent updates
Since the Burndown framework is one that constantly shifts as the micro-sprints inside of it are continually moving to match the needs, wants, and desires of the customer, it’s important to make sure the team is on track and has milestones to hit.
Here’s how we stay aligned on priorities Friday at Drift, the product manager will sit down with the tech lead of each team and talks through the upcoming micro-sprints on the Trello board for about 5–10 minutes. Sometimes it’s clear what the next most important thing is and we’re immediately on the same page. Other times, good points will be brought up in the conversation and micro-sprints/lists will be shifted a bit and agreed upon as the focuses for the upcoming week.
Each Sunday evening, the product manager then writes an internal wiki post with a tactical breakdown of which lists from Trello will be focused on that upcoming week and what value they provide to the customer. This generally takes 1–2 hours but it’s 100% worth it to keep the team aligned as they show up the next morning. If done right, this is the only project management a product manger would need to do on a weekly basis.
That post has four parts (each broken into sections for each product team)…
- An announcement we’d send to customers on Friday if we shipped everything we plan to ship
- Visuals/screenshots (from the HIGH LEVEL cards in Trello) of what will be shipped
- A breakdown of what each engineer and designer is focusing on
- A list of what was shipped from the previous week
At the top of this internal post (#1 in the list), is the written statement directed at a Drift customers. That statement is written as if it were the Friday at the end of the week; it’s exactly what we would announce to our customers at the end of the week if we complete all of the micro-sprints that we planned to tackle. Here’s an example of one for our web app team…
Then, for part #2, I just drop screenshots of all the features, grouped by team. I usually give it a quick title and drop a full screenshot, like this…
For part #3, I put together a bulleted list for each engineer and designer. The goal of this is to be concise and to just show everyone at the company who to turn to for anything specific throughout the week. And to document what each engineer and designer has said are their priorities. I usually do a quick Slack check-in with team members at the end of each week to hear what’s on their mind and course-correct anything if necessary. Most of the time the PM should already have a sense of what each engineer and designer is doing from other conversations that are happening throughout the week. Here’s an example of what that third part looks like…
Part #4 is a short list of what’s been shipped and what’s still underway. This is for the sales and success teams to see what’s been done and what’s almost there. It looks like this…
Remember, within each week there can be 2–4 micro-sprints and we are shipping things immediately when they are completed. These weekly check-ins and updates serve more as a way to ensure that everyone has a sense of what progress looks like and a tangible means to say “I had a productive week” before they head out on Friday. The things posted in the Sunday update aren’t a “this must be done no matter what” kind of list. Sometimes things will happen and things we planned to do are no longer worked on since something higher priority came up that could better impact our current company priorities/themes.
We’re starting to experiment with a new way of communicating company goals and product priorities, which I’ll likely talk about in a next post.
Please, let me know if there are other questions you might have about the Burndown Framework. I believe I covered all necessary aspects of how to make this work at your own company, so let me know if you feel like questions are still unanswered via a comment.