Agile software development requires teams to have periodic meetings to plan iterations, assess progress, iron out requirements, and solve problems. A good practice is to conduct regular meetings - either at the end of a sprint or iteration, or when a product launches - to evaluate what went well and what needs to be changed so the next round of development will operate more smoothly.

Meetings of this type are called retrospectives. When the focus is more on advance planning, the meetings are called futurespectives. Often, there are interactive components to help engage participants and evaluate general mood, set priorities, facilitate communication, raise issues, etc.

Regardless of the kind of meeting you’re holding, attendees that are participating remotely are at a disadvantage. Activities like Is - Is not - Does - Does not call for participants to contribute thoughts on post-its or flip-charts, which are then rearranged as part of the discussion until a conclusion is formed. If you’re sitting in a home office hundreds or thousands of miles away, it can be challenging to get involved in a meaningful way with an activity like this.

Our Internship Program Committee recently faced this difficulty when we were conducting our first retrospective. Most of the team lives near the Holland, Michigan office, but I’m based in southern Indiana. We had been working on revitalizing the internship program for five weeks, and it was time to look back at our progress up to that point, and establish goals for the next phase of the program.

I was keen to try the Success Criteria activity, as a means of capturing and beginning to define what achievement or failure would look like. As written, the process calls for you to use a whiteboard to create a grid. Then, participants separately add post-its for targets (or goals). Those would then get grouped into clusters for similar targets. For each cluster of targets, we could then define what success would look like, and what failure would look like - again using post-its.

A co-worker recommended using Trello instead. I’ve used Trello for years for feature- and bug-tracking; and we use Trello in-house to organize ideas and collaborate on internal projects. If you’re not familiar, the app uses cards, organized into lists (or lanes). I’ve always thought of Trello cards as post-its, so it seemed a natural use case.

Before the meeting, I created a new Trello board for the retrospective and set up the following lanes: “Intention”, “Target”, “Successful If”, “Failure If.” I wanted to mimic as closely as possible the format of the Success Criteria exercise that’s usually done with post-it notes. After getting everything set up, I sent word out to the attendees to make sure they all had access to the company’s Trello account.

Once we reached the “Main Dish” portion of our meeting, I introduced the Trello board to the team. We all agreed that our meeting’s main purpose was to plan for the next phase of our internship program (or, in our case, to iterate our skateboard into a scooter). I asked someone to create a card with that verbiage in the “Intention” lane.

Next, I gave an eight-minute window for people to add cards to the “Target” lane. I instructed them not to think too deeply at this point about how much effort a ticket would take or whether there was already a similar ticket on the board placed by someone else. This is the true brainstorming phase, and aside from the time limit, I wanted thoughts to be as free as possible.

After eight minutes, the “Targets” lane was pretty long, and I realized we would need to adapt the activity format just a bit to the medium we were using. We started reading through the cards together, making topic-centric lanes as we discovered patterns or groupings. We ended up with lanes titled “Documentation Targets” (revamping our program’s documentation), “Assignment Targets” (efforts to uncover work interns could assist with), and “Culture Targets” (changing or highlighting behavior).

We ended up ignoring the “Success” and “Failure” lanes altogether since discussing the brainstormed tickets had taken up the majority of the time.

To narrow down the list of targets to those we wanted to focus on for our next iteration, everyone was given five “dot votes”. Each team member could comment a literal dot - or period - on any ticket they wanted, up to a maximum of five votes. You could vote more than once on a single ticket. The three tickets that got the most dot votes - which were helpfully counted for us by Trello’s comment counter - became our priorities for the next sprint.

I was very pleased with the tool for our purposes, and I expect we will use it again for other retrospectives. We had no write collisions and updates to the board showed up for all of us very quickly. Not only that, but reordering cards and renaming boards was simple. Now we have an instant backlog of features we can draw from for the next iteration!