Things move fast here at Drift. So fast, in fact, that even we were having trouble keeping up with ourselves. We needed a way to get incremental improvements out the door faster, but we found that traditional sprints still took us at least two weeks to ship something new. We wanted a system that would allow us to ship smaller, more incremental updates concurrently.
For months, we hunted for a product framework that let us ship faster than Agile and suited how quickly we ship (which is all the time). Most product development frameworks out there felt too structured, stifling our ability to pivot on a dime. We needed something better.
So, after finding nothing that perfectly fit our customer-driven style at Drift, we threw our hands in the air and made our own framework around principles we knew would help us succeed.
We call it the Burndown Framework, which relies heavily on microsprints and semantic versioning. Microsprints are an iterative piece of a larger feature that can be shipped independently. Semantic versioning is the specific naming structure that helps keep the order of these micro-shipments clearer to everyone on the team.
If we were to build a new version of the Drift customer dashboard – lets call it “Dashboard 2.0.0” – we have two options:
- We could ship the entire thing at once and take two weeks to do that, or…
- We could ship five different incremental updates to customers in two-day bursts.
Which would you choose? To us, it’s pretty obvious. Number 2 is the winner. We call those short bursts “microsprints.”
Along with these microsprints, we wanted a way to keep track of everything that was happening, so we introduced a semantic versioning concept. It ensured everyone knew that when we were talking about updates to a dashboard, we knew which update people were talking about.
(Admittedly, once we got really good with this new framework we weaned ourselves off of semantic versioning. It was kinda like training wheels!) 🙈
We’ve found Trello to be the absolute perfect tool to make all of this work. Burndown favors speed, incremental releases, continual re-prioritization, and flexibility – and we can do all of this in Trello with no stress about our organization.
Solving The Need for Speed With Microsprints
Every microsprint is a list in Trello, each given a title using the semantic versioning. These lists are re-evaluated on a daily basis to make sure that we’re focusing on the right things, at the right times.
Here are the core principles of how we develop products with the Burndown Framework:
- Flexible
- Customer-driven
- Iterative
- Rapid
- Incremental
- Always evolving
- Focused
- Data-driven
Microsprints and semantic versioning lend themselves well to all of these principles. Since we’ve introduced these concepts to our product team at Drift, we’ve shipped crazy amounts of features in a matter of months – all of which have helped our company get on a trajectory toward success faster than we would have been otherwise.
We essentially work from left to right on the Trello boards. Furthest left = what should be implemented next. Furthest right = what still needs to be researched, scoped, and designed.
As a list moves towards the left of the board, it goes through phases of ownership. It will start off as something owned by the product manager.
Once it’s scoped and researched with the help of engineering and design, ownership will then be handed off to design, who will make it a reality. We’ll iterate the design and then the designer will break it out into multiple microsprints that can be shipped independently. These microsprints may wind up being titled things like “Reporting 2.0.0” and “Reporting 2.1.0”
The designer will then coordinate with the engineers to get it implemented and they’ll take the lead.
Semantic versioning helps us make sure that as we’re re-prioritizing stuff in the middle of the board, things don’t land out of order. It’d often be impossible to ship Reporting 2.1.0 before Reporting 2.0.0. That’s a lot like putting the toppings on your ice cream before you actually scoop the ice cream. Madness!
Scaling The Burndown Framework With Trello
There are a few things that make Trello perfect for this framework:
Burndown is a fundamentally visual framework; images and screenshots are at the forefront of feature development and serve as a way to communicate exactly what will be done in each release.
At the top of each microsprint, we create a HIGH LEVEL card with a screenshot, which conveys a visual of what exactly will be shipped in that microsprint. Everyone has access to these boards, and everyone can come in and see exactly what’s coming down the pipeline – salespeople, customer success, execs.
Maximum flexibility and no cascading dependenciesIt’s also super easy to move things around and be flexible within Trello. Burndown and microsprints are a super-fast, super-flexible methodology. We need something that doesn’t lock up when you frequently move things around. Trello makes it a breeze to create and manage new microsprints and give them version names.
Within each product team’s Trello board, the releases are specific to each part of the product, which allows those teams to work through microsprints without being blocked. If there is a microsprint that does have a dependency on another team, we’ll throw a blue “Dependency on another team” label on the card and the engineer who is working on that sprint is responsible for cross-team collaboration.
Because some tools that have dependencies built-in can turn into a giant mess when you move one thing and everything cascades. With Trello, we don’t have to deal with that crazy waterfall effect of “If I move this, is it going to throw off that timeline I set up? How do I make sure this thing is taken care of?”
Handy features like attachments and labelsTrello is also great for attaching design files and having quick conversations about each microsprint. Labels are also helpful as we use a red label to denote that something still needs to be designed, an orange one if it’s blocked, and a blue one of there’s a dependency on another team.
Adopting Trello for Microsprints and Semantic Versioning in Your Product Team
If you’re a larger organization with a strongly rooted process, I’d recommend working within one product team to start (a couple engineers, a PM, and a designer).
Get one team working well with microsprints and semantic versioning in Trello, prove it’s an efficient way to build products, and then scale it across your organization.
If you’re just starting up or building, you should start with microsprints in Trello and bake it into your product culture.
The idea is to design two or three weeks ahead (generally about 10-15 microsprints ahead). We don’t want to get too far ahead because then it becomes too visionary, and things change rapidly as a startup. Each engineer assigns themselves to one card at a time, and they’re solely responsible for getting that part of the product shipped.
Here’s how our semantic versioning system looks...
N.x.x (Major Release)
A major release is when a brand new part of the product is introduced or an existing part of the product gets a complete overhaul.
x.N.x (Minor Release)
A minor release is when a new feature is introduced within an existing part of the product.
x.x.N (Patch)
A patch is when an existing part of a feature is tweaked slightly.
Again, semantic versioning is like a perfect set of training wheels as you and your team get started with microsprints, so take them seriously and stick with them. When you feel like they’re truly getting in the way of your speed, that’s when you know they no longer necessary. For reference, it took us about 3-4 months to get there.
At Drift, our product teams are split by different customer-facing aspects of the product, which allows us to ship things independently. Splitting product ownership by code base, if possible, helps you avoid dependencies, which is key to getting this process working for your company in the long-term.
MicroSprinting Your Way to Better Products
If you’re anything like us and are customer-driven to the core, microsprints and semantic versioning are your best way to build products, faster.
In a world where software solutions are becoming commodities, you need an edge, and that edge is going to be how flexible you are and how quickly you can respond to market changes and customer needs. With Burndown’s microsprints and the power of Trello, you can grab the competitive edge in flexibility and responsiveness.
If you have any questions about Burndown, microsprints and semantic versioning, I wrote more about our process here. I’m also happy to talk through anything! Feel free to contact me at matt@drift.com or @mattbilotti on Twitter.
Good or bad, we’d love to hear your thoughts. Find us on Twitter (@trello)!
