How we use Trello and Google Docs to continuously improve UserVoice

Last fall, when I returned from vacation, I discovered that Dehana, our Product Manager in UserVoice , had replaced my favorite Roadmap in Google Docs with the Trello board.

My initial reaction to such changes was by no means positive. The problem was not the Trello itself, but the way we used it. Trello is a VERY open project. There is no single “right” way to work in Trello, so in order to feel at home in it, you will need time to customize it.
')
So, after much experimentation, we seem to have managed to get a system of work that suits us completely, and we decided that we should share it with everyone. This post will be longer than usual, and if you are far from the topic of web development, it may seem a bit boring to you. If you decide to go straight to the part of the post dedicated to the lessons learned, I will undoubtedly be upset, but I will not be offended.

Our process

Our development process combines 6 different Trello boards. The central link is the Current Development board. The main purpose of the other boards is to provide cards that represent improvements or bugs (see below), Current Development boards, and specifically its Next Up columns. The Next Up list is our only list, the tasks in which are sorted by priority. Developers and designers look into it when they are ready to start working on a new card.

However, before we consider in detail the functions of all our boards, let's talk about the “blood bodies” in our “circulatory system” of development: about the Trello cards.

Cards

Each card is one of the user stories. This may be an improvement, a task for processing or a bug.

Cards with improvements appear as a simple idea, 1-2 sentences long. However, before they can be sent to development, they increase in volume and now include a link to Google Doc with a detailed specification, a set of interface schemes (wireframe) or coarse layouts.

We use the term "specification" (spec) in a fairly broad sense. These are not the specifications that come to your mind when you remember the work on the coursework at the university or the work in that crappy consulting company immediately after its completion. In our case, the specifications reveal the user story in detail: why (from a business point of view) we take it, what we hope to achieve, and, if possible, include some notes on its intended implementation (although this point remains at the discretion of the developers; help, but not required). Good specifications also contain a link to the source and related idea on our UserVoice forum.

If the card describes a bug, then it contains steps that help to reproduce it (well, if a screencast was also added), and a link to the ticket in the UserVoice Helpdesk , where the bug was originally described.


Link to one of our real specs

Our kitchen

Board Current Development is a board on which "the history is created". It contains the following columns:

Next Up (“Next”)

• A list of all priority cards, verified and ready for design and development.
• It is worth noting that the developer or designer does not have to take the very first card in the list for work. It is better to take the top card of those with the implementation of which you can exactly cope.

In Progress

• These are the cards that are in the process of active design or development.
• If you take a card, you attach your avatar to it, thereby securing it. Developers have a rule that, following which, one cannot secure more than two cards at a time: one main project and one additional one.
• When a developer takes a card, he assigns a due date to it so that the others are aware of the expected date of sending this card to QA. A quick look at our board at Trello showed that the implementation of this rule leaves much to be desired.

QA

• When the engineer considers the task completed, the card is checked for performance and move it to QA. From now on, our QA manager and UX manager are responsible for evaluating the result and deciding whether he has the right to life.
• As mentioned earlier, if the card is a project of a major improvement, we highlight a separate Trello board dedicated to the problems encountered in the process of testing this project. The project card will remain in QA until all cards that are on a separate board of this project and containing its problems are resolved and removed.

Launchpad ("Launch Pad")

• These cards have been tested in QA and are ready to be launched (however, this does not necessarily happen later on), and most often include GitHub Pull Requests associated with them (the person who created it will supervise the request. Although there are no strict rules: supervise the request everyone can.
• If the card contains a bug fix or revision, it is put into operation immediately, but no later than 3 am Pacific Time. Unless you, as a developer, want to spend the next hour and a half on the monitor and see if there are any problems.
• If the card contains an enhancement, it will also be launched, but it will be hidden from the end users using the “feature flag” (the “Feature flag” allows you to enable the new feature for selected accounts). The improvement will be immediately available for our own UserVoice account and for all users with early access to new features. In other cases, the card will go to the Marketing Department and will be open to all accounts after the official release.

Live (“Launch” (Week #))

• These cards are already running and are no longer hidden from users under the "feature flag".
• The only people who can send a card to “Launch” (essentially this is our list of completed tasks) are the Product Manager (if it's an improvement) and the Bug Reporter (if it's a bug fix). This helps ensure that the feedback loop is complete before we stop following the card.
• Every week a new Live column is created in Trello so that we can track what was launched and when.

In addition, we use three labels that can be attached to cards:

• Bug - Bug
• Staging - Health Check
• Production - Getting Started

Pretty simple, right? This approach to development is very similar to the kanban system. Now let's see how the cards fall on this board.

Mom, where do the cards come from?

New cards can appear from 4 different boards:

Product roadmap

• It contains all the major projects for each quarter, moreover, there is a rough plan for 3 quarters ahead. These large projects are moved to the Planning board with the start of the corresponding quarter.

Inbox ("Incoming Ideas")

• There are two columns here: one with ideas from members of the company, and the other with ideas from our users (linked to the corresponding support tickets on UserVoice Helpdesk and ideas coming to our user feedback forum UserVoice ).
• We review ideas on this board during our weekly meeting to review incoming ideas (see below).

Bugs

On this board are 3 lists:

• Inbox is unchecked bugs.
• “Requires add-ons” - here are the bugs, with the reproduction of which we have problems and which require additional information from the person who reported the bug.
• “Accepted” - yes, it is very likely a bug.

• If the bug gets into “Accepted” and the client team decides that this bug is “critical” (you can find out how we solve this issue by reading our post “ Our critical issue escalation process ”), then it is immediately moved to Board Current Development and urgently contact our "duty developer".

• If the bug is not critical, it remains in the column “Accepted” until the head of the Client Relations Department moves it to the column “Next week”, which contains bugs that should be fixed next week (cap). One condition - he has the right to choose no more than 7 bugs a week. You ask why 7? Because there are always plenty of bugs, and the customer service team always wants to fix all of them, but if we learned something, it’s necessary to limit the amount of time that can be devoted to eliminating (non-critical) bugs.

Engineering ("Development")

• We have a list of areas where code restructuring may be required. Each list is a separate category (for example: Backend, Frontend, Tests, Infrastructure), and each card is a separate project on refactoring or another project not directly related to users.
• Developers can optionally take cards with small questions and put them in In Progress; larger cards should be placed in the Next Up column for pre-planning.

Who said central planning doesn't work? (Planning board)

The “Planning” board is a board where I spend most of my time with our PM and UX manager. It includes the following columns:

Next Up (“Next”)

• A list of the following projects that we want to launch in development, placed at an approximate priority.

Spec ("Specifications)"

• A card in this list means that it is necessary that someone write a specification for it. Before this happens, the card is usually just a general idea.
• We use Google Docs for writing specifications and rely heavily on contextual comments to discuss (not organized, but individually) any controversial issues with other team members. Any rather complex controversial concept will be considered in detail at an improvised project meeting (more on this in the next section).

Design ("Design")

• A card in this list means that it is necessary for the designer to look at it. This does not necessarily imply the creation of an interface circuit or layout, since the design phase involves not only addressing the appearance, but also considering the requirements of acceptance criteria and resolving issues related to design principles, usability, production processes, as well as influencing existing functionality — its actual checking and correcting any faults before the card goes to the development stage. (Also, if it turns out that more work needs to be done on the acceptance criteria for the card, it is again sent to the Spec list).

Ready ("Finish")

• Here are the cards tested by the initiator of the idea and the design team. Sometimes they come with interface diagrams or other necessary artifacts. Now everything is ready to be moved to the Next Up list on the Current Development board (after discussion and verification at a planning meeting).

On any board other than Planning, the cards always move exclusively from left to right. But on this board, cards often move from Design or Ready back to the Spec column (sometimes repeatedly) before they finally get onto the Current Development board.

Our meetings (or how we move cards from one board to another)

We only have a few weekly meetings:

Monday Morning - product meeting (30 minutes)

• Present: all company employees
• A general meeting is held so that everyone is aware of what is happening, as well as to celebrate recent successes in the work of our development team. Our PM leads the meeting, and this is the only meeting for which a presentation is necessarily created.
• We single out one slide for a review of bugs fixed last week, using avatars to show who exactly fixed them. You always feel proud when you see your photo next to a long list of fixed bugs.
• Each new feature is placed on a separate slide along with the avatars of all the people involved in the work on the project, the number of points as well as a screenshot or (more often) video. Each participant in the project is given 20-30 seconds to explain to the others what exactly was done.
• PM or CEO talk about all new projects that have moved to the Next Up column, and provide more detailed information about what these new cards are and why they are priorities.

Friday morning - meeting on the review of incoming ideas (30 minutes)

• Attendees: PM and UX Executive - required, all others optional.
• If you add a card to the Inbox board (it doesn't matter in the ideas column of users or company members), it is expected that you attend this meeting and personally present the history of this card (you can read the details about how, from our point of view, the reverse communication with users ). The main goal is to help other team members understand your case. To make sure that we are dealing with the most pressing issues, we have limited the number of cards per person to 3.
• The secret of how to adhere to a given topic at this meeting is a discussion of the problems themselves, and not ways to solve them.

Friday Afternoon - Planning Meeting (1 hour)

• Present: CEO, PM, UX Manager, Lead Developer
• The purpose of this meeting is to review all the cards that are on the Planning and Engineering boards and are ready to be moved to the “Next Up” column on the Current Development board. Before moving the card, we need to make sure that there are no unresolved questions or tasks on it and that we can discuss the next step (for example, do we need to design a prototype first?). As soon as all the cards from Ready are moved to Next Up, we will re-sort all the cards in this column by priority (yes, even if the card was at the top of the list last week, this one can move to the very end).
• We also determine the difficulty level of each card. We rate them as simple (1 asterisk), medium complexity (2 asterisks) and complex (3 asterisks). This assessment is based on previous experience (the experience of the company, not individuals): did we do something similar before, how familiar are we with this field of activity, do we have our experts in this matter, etc. We use the cards to make it easier for developers to understand how complex and time-consuming they are, and also to show the importance of the cards to the rest of the team during the meeting on Monday.
• And finally, we consider all the cards with bugs, which the customer service team set the status to "Remove next week." If the card does not contain enough information or if it is supposed to take a long time to develop (more than a couple of hours), we do not send it to the “Next Up” column. All cards that move to “Next Up” automatically get to the top of the queue. We want to be sure that first of all we always repair what is broken.

Every morning - Stand-up (10 minutes)

• Present: all members of the working group (designers, developers and QA)
• In Skype (we have two offices) on Mondays, Wednesdays and Fridays, and using HipChat on Tuesdays and Thursdays (our quiet days without internal meetings).
• We try to have team members discuss what is needed to complete their tasks on a stand-up, rather than a boredom like “I did it, and I do that.”

These are all our “official” regular meetings, however it is worth mentioning that often we, together with the UX Head and PM, hold improvised three-hour meetings where we discuss in detail the design and design issues by sorting a few cards from the Planning board.

These impromptu design discussions are usually held closer to the end of the week (Thursday / Friday), when it becomes clear that there are different opinions about the cards we worked on all week. For me, this is one of the most productive and interesting meetings that we hold. Outwardly, they may seem unproductive, as often after discussion we return to where we started. But in reality, this is a sign that we are really well aware of all the pros and cons of the path we have chosen: we make our decision consciously, and not blindly and in a hurry.

Lessons learned

Always @ contact someone in the comments to the card if you really want to get an answer
If you write a comment to a card without addressing anyone specifically, it means that you wrote it as a note for yourself for the future. If you want someone to pay attention to your comment, indicate who it should be with the @ symbol in Trello.

A single list of tasks by priority for the working group
Initially, we had columns of cards, arranged by priority, for each separate application of the product (admin console, widgets , iOS , web portal, email). This could work if we had separate working groups for each subsystem, but we don’t have them. This only led to confusion about what kind of task should really be next. It was also extremely inconvenient to determine and monitor what exactly the team is working on at the moment. (Tip: if you notice that you often use the Trello horizontal scrollbar, it means that you are doing something wrong).

Do not use a separate system for bugs.
Initially, we left our previous bug tracker in the work, and Trello was used to develop new features. This caused problems for the same reasons for which a large number of columns did not work: as soon as we started using more than one list, any prioritization ceased to work.

Limit the amount of time to solve problems with bugs.
We achieved this by setting a limit on the number of bugs that can be added weekly to the Next Up column. Initially, this decision was made a bit ambiguous, but later it helped prevent a lot of controversy about whether to consider this or that bug. Now the client team has the right (and maybe burdened) to choose standing cards. This is a peculiar version of the "Hunger Games" in the development.

Add and sort cards in the Next Up column only once a week.
This will help not to turn the Next Up list into an ever-growing sand dune. After new projects are presented on Monday morning, you know exactly where in the queue they will be for the rest of the week. You do not need to worry that the project you wanted to do will be at the end of the queue (and you will not be able to carry out your plans) in the middle of the week.

Good specifications tell a story rather than a step-by-step recipe.
For everyone to work on the project with full dedication, they must clearly understand why they are doing this. Therefore, it is important to clarify the problems of users (or business) to the developer, who is to solve them.

Do not attempt to make a preliminary estimate of the project deadlines.
Earlier, when we worked in sprints, we spent A LOT of time (almost a whole day on a 2-week sprint) for preliminary assessment and planning in vain attempts to draw a line and say: "We will deal with these cards in the next two weeks." We did a lot of work and still almost always made mistakes, so we stopped struggling with uncertainty.

Try to celebrate your successes.
It is important to understand that unfinished work is always there. Every week we create a separate column for cards that are put into operation, so that we can understand what we have achieved this week. We also use photos of everyone who successfully completed the task at our meetings on Mondays.

I hope this article was helpful. I express my well-deserved thanks: Dejana Bajic (PM), Joshua Rudd (Head of UX) and Jonathan Novak (Lead Developer), for creating this reliable process.

Useful links from the translator:

“ A Guide to Productive Work at Trello. Useful extensions and settings » »

“ How do you use Trello for agile development? "- Quora-thread

" Five Tips for Using Trello for Scrum "