Create a separate board for each process you want to manage. Create columns to represent each stage of the process. Create cards to represent a task--then move the card between columns as it progresses through different stages.
Trello lets you assign people to tasks to track who is working on it. The cards let you track discussions, attachments, checklists, and all the information you need to capture the state of the task.
Put a card at the top of each column. Add a concise explanation of the column's purpose. It's a useful reminder for your team.
I find it helpful to put these cards at the top of the columns as a reminder. One note: Trello has a handy feature to move all cards in the column to a different column (even a different board). Unfortunately using these "header" cards makes that feature difficult to use (remember to move the header card back to where it was). If you want to streamline your process even more and trust your team you can omit the header cards.
Edit this card and turn on a bunch of labels to make your column's instructions stand out.
Trello has color-coded labels you can turn on for your cards. Labels are a handy way to visually differentiate your tasks (eg: mark critical items red, bugs orange, code tasks blue...). In this case, I turn on several of the labels on the "header" card to get a nice rainbow pattern on the card simply to make it stand out from the others.
When you start your sprint, put all of the cards for the tasks you've committed to completing this sprint here, in the "to do" column. No one should be allowed to add anything here without the scrum master's permission. Ideally the stories here come directly from the backlog and bug boards's "next sprint" columns.
GET THIS RESOLVED ASAP--DON'T LET THIS GET BACKED UP!
If a card cannot be finished for some reason it goes here. Blocked cards represent a risk to completing the sprint and should be addressed immediately. Don't let this column get backed up. If there's something in here that can't be resolved in a timely fashion then it's best to move it to the backlog--and if there's an external dependency, make sure that you get a card in that team's backlog to address it.
After a developer is done with a task its card should go into the test column. The card should have a checklist of acceptance criteria or at the very least a short explanation of what to test. A different person should assign the card to themselves, test it and then either move the card to "done" (if it passes) or back to "doing" (if it does not pass). Make sure to have a conversation with the person who originally did the work and add some useful information to the card so they can quickly fix whatever is wrong.
Only tested cards go here. In very rare cases there may be a task that is not testable, or sometimes there may be a task that is self-evidently done. In these cases it should be sufficient to get agreement from the team that the task is complete and you can move it straight to "done."
*NOTE: "bug free" does not mean perfect--but good enough. ;)
Your product owner (and sometimes developers) will add cards for new features to the "new stories" column. Put as much information and acceptance criteria as possible into the story--but don't waste time trying to over-specify every last detail. Each story should be concise and understandable. When the developers get together to estimate the story, if they need more information they can ask the product owner.
When the developers are estimating stories, ones that lack sufficient definition go into this column. Its the responsibility of the product owner (or the person who wrote the story) to add more details. Next time the team gets together to estimate, go through this column before getting to the new stories.
This is where the defined and estimated stories go. The product owner should keep the cards ordered by importance. The most important things go at the top, the least at the bottom. If your scrum master does a good job of tracking your teams velocity, it should be possible to add up the estimated point values for the cards in this column and have a rough idea of when the team will be complete.
When it's time to plan the next sprint, the team will look at its average velocity, consider what their capacity is for the next sprint (maybe someone will be out, maybe there are a lot of bugs or some roll-over stories to complete...) and then grab as many cards off the top of the "backlog" column as they think they can handle and put them here. The cards in this column should also be ordered by priority.
Anyone at the company should be able to add a card to the "triage" column. This is where your incoming bug reports go. Put as much info as possible into the bug report. Indicate how severe and frequent the bug is. Consider using a label/color scheme for this. At our company we like to have a weekly "bug bash" where everyone gets together, tests the latest build and files bug reports--here in the "triage" column. Then the devs will get together, assess the importance of these bugs and assign them to one of the other columns. Don't let your triage column get backed up--bugs are timely things and best handled immediately.
NOT A PRIORITY FOR THE NEXT RELEASE, BUT IF YOU HAVE A SEC...
I'm fond of the "now or never" school of fixing bugs. Either it's important enough to fix it now, or you'll never get to it. However, I like to have a "low hanging fruit" (or "LHF") column for those bugs that really are just a quick fix (eg: less than 15 minutes, definitely no more than 1 hour) and would have a noticeable impact on the quality of the app. If someone has a spare moment they can grab something from this column, fix it, and have a disproportionate impact on the perceived quality of the app.
Here's where the really important bugs go. These are bugs that break features you've already delivered or are broken in production. Sometimes you will have something that needs to be fixed immediately. In those rare cases the scrum master can move the bug into the current sprint (weigh that decision very carefully because in you don't want to put completing your current sprint at risk).