Managing Effective Design and Development Collaboration in Trello*
The beginning of a project is always exciting.
During these beginnings, our minds are always buzzing with questions: What’s the problem we’re tackling? How will it work? How will we evaluate success? What will it look like?
We want to try new things with the project — New tech stacks, new design methodologies. Things are going to be different from last time, we say.
And then this happens.
Managing the day-to-day in a project is a long and challenging road. We’ve noticed patterns emerge with most projects, a few weeks or months into the engagement. Maybe these patterns sound familiar to you:
- User stories are not properly defined off the bat. High-level, conceptual work is great. It’s essential that everyone on the team gets the big picture. Things fall apart when we get into the nitty-gritty. Stories are incomplete because we did not consider all the potential aspects and a definition of “done”.
- Design and development get out of sync. Let’s say you have to design a user flow that will inevitably involve design and dev tasks. Designer begins sketching or mocking up this flow. Engineer begins researching or establishing backend. When do the two converge?
- Stories “in progress” pile up. Suddenly, everyone’s “working” on 10 stories at once.
- For every story that gets delivered, 10 bugs emerge to fix that story. Fixing every bug is suddenly more important than anything else you were supposed to do.
We’ve experimented with a few project management solutions to handle these problems. Several months, projects and a fair amount of tinkering later, we’ve devised a way to make Trello effective for us.
Here are some tricks and tips we’ve picked up along the way, in case you’re interested in trying out Trello for your team:
Everyone on your team needs to be on board.
Full participation is a major challenge in adopting any new collaboration tool. I know not everyone is a fan of Trello. It may not seem enough compared to more robust project management tools.
Trello acts as a way to let the user move cards around on a board to visualize workflow and to display a change of state. While this may be easy and fun for some people, it may be cumbersome and overwhelming for others. Listen to your team and learn the ways they prefer to see tasks and show progress. Maybe Trello isn’t for your team.
For each project, separate big picture user flows and user stories.
So your whole team is on board to give Trello a whirl. Cool! Trello relies on cards to visualize tasks and each card takes up a good amount of space on your monitor. Don’t try to cram everything everyone needs to do on one board.
I’ve found it easier, visually and conceptually, to keep one board for your Epics and high-level task flows, aka a Story Map, and at least one other board for the actual stories you will complete, aka a Sprint Board.
For example, let’s say we want to build an app that lets people create and vote on ideas to be discussed during a meeting. We’ll hold a series of ideation sessions to map out the high-level goals we want users of this app to be able to do. For this kickoff and ideation phase of the project, use the Story board to document your big features.
Now that we have a base to flesh out what a user needs to be able to do to achieve these goals, decide with your team which stories your team will need to build out for your first sprint. Copy these stories into a new board, the Sprint Board.
Write and discuss your tasks thoughtfully.
So you have some stories that your team has determined will be built for the first release. Great! Now it’s time to discuss and flesh out the details. Here’s how we structure a story in Trello:
Name of the story: There are different schools of thought on how to write an effective user story. One that I’m fond if is the “job story”:
As a [type of user] I should be able to [do this task] so that I can [accomplish this goal]
Description: A good story description covers the potential scenarios each story accounts for and what it will take to get this story done. It’s essential that your team does not rush through this.
Acceptance Criteria: This is what the product owner references to accept, aka bug-free and production-ready, a story. The philosophy behind each story is that everyone involved in this task (whether it be a designer, dev, content strategist, what have you) is responsible for a portion of its completion.
In-person Discussion: This should go without saying. Take the time to sit down with your team for 60–90 minutes to discuss ambiguities, level of effort, and division of responsibilities.
Points?: Trello has a convenient pointing power-up you can implement to your board to assign points. However, on a higher level, we’ve been having ongoing discussions on how to estimate level of effort across design and development stories. If you have methods that work for you, let us know!
Work like a relay race.
So you have the tasks of your first sprint discussed and ready to be worked on. Wonderful. Now how do we manage the shifting hand-off between design and dev?
Only work on what you say you’re working on.
The “Current” column in Trello is meant to be the source of truth. Showing what I’m really working on is, well, the best way for your team and your stakeholders to know what they can be working on. Let’s look at an example where this is valuable:
Problem: I start working on a story and I move it to “Current”. I don’t get through it because of a bug. I drop it out of frustration and pick up another story. I suddenly have two stories in “Current”. Another developer takes a look at “To-Do”, sees two stories in “Current”, and picks up a “To-Do” story. There are now two new features in progress and one buggy story that sits there. If this scenario has happened to you before, you’ll know that this can swiftly mount up a pile of buggy features and technical debt.Solution: I start working on a story and I move it to “Current”. I comment on the card that I need help with this story, and I move it back to “To-Do”. Another developer takes a look at “To-Do”, sees the comment, and the two work together to fix the bug.
This means I can’t really work on two things at once. Here’s a health check we regularly employ on “Current”:
Are there as many stories as there are members of the team in “Current”? If not, ask your team to check “Current” and ensure that the source of truth still holds.
Leverage columns and visual movement.
Given that most tasks we do involve design and engineering work, it’s going to be passed around. Rather than draft a set of wireframes that document the entire system of a product, designers work incrementally, task-flowing and sketching one story at a time. One of the biggest challenges we face with this workflow is leveraging a project management tool to easily document and track progress with the whole team.
In Trello, we let columns act as this design and development status check. Let’s track the lifecycle of a story:
1) From the Backlog, we decide as a team to move a story into this week's sprint, the "To-Do". We discuss the criteria needed for acceptance and write it out on the card.2) Michael pickups up the story and moves it to "Current". He attaches his face to the card to claim ownership of the story.3) Michael finishes the structure, services and puts front-end data into a view. From a back-end perspective, the story is done. So he puts it in "Ready for Design" with the comment: "Archive exists now but it's just a simple list. Could use some front-end and design love."4) Brooke sees the "Ready for Design" story and picks it up. She moves it to "Current" and attaches her face.5) Brooke finishes front-end styles, and she opens a pull request on Github. It gets accepted! She moves the story into "Ready for Staging (on Master)"6) The team gears up for a round of QA and so the story is deployed to a staging server. The story moves to "Ready to Accept (on Staging)"7) But wait! A bug emerged during QA. We attach a red "Bug" label and move it back to "To-Do". We'll pick it again another day. The sprint goes on.
Don’t be afraid to go “backwards”.
As you can see above, just because a story isn’t literally moving forward, it doesn’t mean it’s not progressing. The fun part (at least to me) about Trello is that it represents the dev cycle in a realistic way — that features can get passed around, can get blocked and can be rethought.
We use a legend to additionally color code the bugs and blockers that come through with any story.
Continue experimenting.
While reading this, you might have been thinking, “these tips could apply to any product management solution, not just Trello!”
Trello isn’t perfect for everyone and is by no means the tool. If reading this article also made you think, “Well, [this tool name] solves [this problem] better!” we’d love to hear it.
Tells us what you think below. ;)
