Here are just a handful of ways we’ve used Sifter—and seen our customers use it—and how our various statuses are useful in each situation.
The obvious one. We track all of our own bugs in Sifter, and this is its most popular use. With bugs, the “resolved” status represents the point at which has been fixed, and “closed” means the fix has been reviewed and approved. With smaller bugs, we might skip retesting and just close them, but with larger, more complex bugs, we mark them as “resolved” and review them in our staging environment before we close them.
Questions and Discussions
Code can’t solve everything. Sometimes you might have problems that aren’t related to code or higher-level questions that need an answer. Maybe you’re trying to figure out your pricing model: you can put that in Sifter and discuss it among your team. Or maybe you’re evaluating a couple of vendors—sure, stick that in Sifter too. Then once you and your team have hashed things out, you’ll still have the discussion thread that you can refer back to later.
We set up an internal project just for ideas. You might be thinking, “Oh, like a backlog or an icebox?” Well, that’s part of it, but that’s just the start. We’ll talk about things like new features or marketing ideas—or even code that could use a little refactoring. And what we like about having a project like this is that we can toss an idea in there without having to worry about whether it’s perfect or even realistic. Some work out and end up being implemented, and some don’t—and that’s okay because the issues we cast aside aren’t littered throughout our primary project. And if we give an idea the green light, we can just move the issue to our primary project and get started on it.
We’ve found Sifter pretty handy for keeping track of not only our internal ideas but also our customers’ ideas and suggestions. So, in they go: we keep track of all our customer’s ideas in our ideas project as well. Each person on our team can add their two cents. Some customer ideas work out and some don’t, but either way, all our thoughts are captured in Sifter. And if we ever get second thoughts about an idea, we can always check back on our original discussion to remind ourselves why we went one direction or another.
Tasks and To-Dos
Sometimes things come up that aren’t about fixing something that’s broken—it’s just a new thing that needs to be done. When our SSL certificate is getting ready to expire in a few months, we’ll create an issue to keep track of it. And whoever is working on it can keep track of their progress there. But here’s the best part: when anyone wants to see the status of, say, how the SSL certificates are coming along, they can just glance through the issue without having to bug the person who’s working on it.
Sifter is just a robot, and it doesn’t know what kind of stuff you’re putting into your issues. And for the most part, as long as you know what they are, that’s fine.
Sifter can be handy for tracking stuff, but it’s only as good as the data you put in there. If your team comes to a verbal agreement about something instead of focusing that discussion through Sifter, there’s no way to search through the text of that discussion later. (Yeah, we figured that out the hard way.) So even when we verbally agree to something elsewhere, we’ll file it in Sifter as well.
So when someone on your team has an idea for a feature, you may as well put it in Sifter to talk through its pros and cons. Or if you get a feature request that catches your eye, sure, toss that in Sifter too. And that’s just the start—just about anything you might need to talk through or keep track of can find a home in Sifter.