Trello For Software Development
Published on Nov 18, 2015
Trello is a free and easy system for managing a project's progress. In this presentation I show one way of using it to facilitate the software development process.
MORE DECKS TO EXPLORE
PRESENTATION OUTLINE
Tame the software development process with Trello (and a little discipline).
Trello is a free web-based tool to help organize and track projects. If you're running a small, LEAN/AGILE software development team it's a great tool for both planning and tracking progress.
Photo by missresincup
WHY TRELLO?
- It's easy
- It's free
- Keep track of your progress
- Collaborate remotely
- Track bugs/feedback
Sign up for Trello here (if you use my link it'll help me out): https://trello.com/nickhart/recommend
Photo by Seth and Alexa
HOW DOES IT WORK?
- Organize by process
- One board per process
- One column for each stage
- One card per task
- Move a card to mark progress
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.
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.
Photo by Gustavo da Cunha Pimenta
USE THREE BOARDS:
- Sprint
- Backlog
- Bugs
For tracking the software development process I recommend using three separate boards. If you have separate teams then you'll want each team to have their own boards.
Photo by Leo Reynolds
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.
THE SPRINT BOARD
The sprint board is used to track the work you are currently doing. If you want to know more about what a "sprint" is, I recommend reading some resources on AGILE and Scrum. http://en.wikipedia.org/wiki/Scrum_(software_development)
TO DO
TASKS WE ARE GOING TO DO THIS SPRINT
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.
DOING
IN-PROGRESS TASKS--DON'T LET THIS GET CLUTTERED!
This is where cards for tasks being actively worked on go. Don't let too much stuff accumulate here. It's best to finish any started tasks before starting new ones.
BLOCKED
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.
TEST
A TASK ISN'T DONE UNTIL IT HAS BEEN TESTED
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.
DONE
COMPLETED, TESTED, AND BUG-FREE*
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. ;)
*NOTE: "bug free" does not mean perfect--but good enough. ;)
DANGER!
Photo by Nina Matthews Photography
Finish in-progress tasks before starting new ones. Look for incomplete tasks (in test or blocked) and see if you can help. This requires a little discipline and initiative.
Photo by Andrew_D_Hurley
THE BACKLOG BOARD
This board is used for planning purposes. It's where new stories are added, defined, estimated and ordered. It's also where you will plan your next sprint.
NEW STORIES
WHERE FEATURES ARE BORN...
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.
NEEDS DEFINITION
WE NEED MORE DETAILS BEFORE WE CAN ESTIMATE
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.
BACKLOG
DEFINED, ESTIMATED AND ORDERED BY PRIORITY
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.
NEXT SPRINT
TO DO NEXT SPRINT, ORDERED BY PRIORITY
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.
Don't forget about your bugs! Plan some time in your next sprint to tackle them. It's easier to fix them now rather than later--and a buggy feature isn't truly done.
Photo by Joint Base Lewis McChord
THE BUG BOARD
This is where bug reports go and progress on bugs is tracked.
TRIAGE
INCOMING BUG REPORTS GO HERE
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.
LOW HANGING FRUIT
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.
NEXT SPRINT
WE WILL FIX THESE NEXT SPRINT
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).
TRIAGE TIPS
Photo by Official U.S. Navy Imagery
Think hard about the relative importance of a bug compared to all the other work you have to do.
Photo by Mike Disharoon
Is a feature you've delivered broken by this bug? Fix it.
Photo by Herr Olsen
If it's not a priority, but not too difficult and would have a disproportionate impact on the quality of the user experience, consider putting it in low hanging fruit."
Photo by onnola
Otherwise dispose of it. In a perfect world we'd fix every bug. Besides, If it is truly important it'll keep rearing it's ugly head.
Photo by i k o
Color code your cards. Know at a glance if a card is a bug, story, chore, dependency or something else.
Photo by anieto2k
Use the Scrum for Trello Chrome plugin and make tracking your story points easier.
Photo by cgt
Tailor your process to suit your needs, but work with Trello--it's easy and uncomplicated. If it won't do what you think you need, maybe you're making your process too complicated!
Photo by flickrnospam
HTTP://TRELLO.COM
Sign up for Trello here (if you use my link it'll help me out): https://trello.com/nickhart/recommend
