I’m not gonna outwardly admit I’m lazy, but I don’t like to repeat things or work on tasks that could be easily automated. To that end, I’ve created a project template and it’s been useful enough to me and my colleagues that I figured I’d do a brief walkthrough of what all the different fields mean and how to get the most use out of it.
Keep in mind that every project has a manager. If you’re a freelance developer flying solo, that means the manager is you.
Throughout my career as a team lead, project manager and scrum master I’ve always come back to this template. I’ve made a few minor updates over the course of several years, but for the most part the overall backbone of this project template has remained the same and it’s served me well in leading my teams towards success.
You can check out the project template here.
Resources
This column is the least likely to be updated on a frequent basis, but configuring it correctly is key because what you put here determines how useful this template is.
The Resources swim lane provides a key for reading labels, keeps track of the overall progress of the project, lists contact information for all involved parties and gives a space for your team members to provide updates on how things are going. I’ll go into each of those in a little more detail.
Label Keys
This is an explanation of what all the different label colours mean and how to use them. In the linked example, the labels are keyed as follows:
Green: Review request. Tag items green if you need another pair of eyes to review your work.
Orange: Help. For those tricky tickets you need assistance with whether from another team member or third party support.
Red: Priority. An easy visual to show this ticket needs to be completed before lower priority items.
Purple: Team A. This ticket is the responsibility of Team A.
Blue: Team B. Tickets labeled blue belong to Team B.
Navy: Next Version. Items tagged this colour are ideas or requests for the next iteration of our product.
Launch Timeline
This is a simple timeline that contains major milestones for the project along with their associated deadlines. Staying on top of this timeline is as easy as crossing stuff off a checklist, and it feels so good.
Stakeholders
The purpose of this card is to list contact information for any of the major players for your project as well as external resources that may not have their info available in your company directory.
In the comments section of this card, I’ve included a template with fields for name, company, phone number, email and a handful of other useful bits of info. Just copy and paste that into a new comment and you’re good to go.
Weekly Updates
On this card, your team will post weekly updates on things they’re working on at a high level. This should be kept pretty short, maybe 2-3 sentences per team member and gives you a historical reference on the progression of your project.
Weekly updates should be posted here in a comment. You can have each team member post their own comment, or aggregate all of them into a single comment to make it easier to skim the project’s history.
Questions for Next Meeting
On to the next column! As a Project Manager or Scrum Master, this is where you should be focusing your attention the second most (we’ll get to the most later!). In this swim lane, your team members will post questions aimed at the overall team – this is particularly useful for those cases when they don’t know who to ask for something, or when a design decision needs to be made with input from a larger group.
Just because the title of this column says “next meeting” that does not mean you have to wait until the next team call before you can address it! Ideally you want to keep a constant eye on the stuff that comes up here so you can minimise any downtime for your team. Then when you do get to that team call, you can spend more time on the real head scratchers that need to be hashed out with everyone.
To Do
This should be pretty self-explanatory – each card in To Do is something that’s not finished yet. This helps you keep track of who is working on what, and if you’re using labels correctly it’ll help you identify any tickets that are stuck before they get really bad.
Each card in the To Do column should contain the following:
- A complete user story, including business value.
- A list of acceptance criteria
- Any relevant wireframes, designs or code snippets
Ideally, you don’t want more than one or two cards assigned to the same person at once unless they’re all very closely related and cross-dependent. This helps your team members to focus on the task at hand without all the other to-dos cluttering up headspace. Just leave other stuff that’s not being immediately worked on unassigned for whoever’s free next to pick up.
Pending
Tickets in Pending are nearly done, but not quite over the finish line yet. They may need someone to provide a peer review, they may need testing, or they may need final approval from stakeholders. “Pending” is a sort of catch-all for “finished with active development” and can be split into other columns like “QA” or “Product Review” as needed.
Blocked
Tickets here are stuck and need help to get unstuck. Most of the time, cards in this swim lane need your intervention to move forward. Some examples I’ve seen before:
- Some verbiage needs clearance from Legal before it can move to Production.
- Feature B depends on some code in Feature A, but Feature A isn’t finished yet.
- A developer picked up a ticket to change a site theme, but there is no design or mockup attached to the ticket.
- The ticket meets acceptance criteria, but QA still has quality concerns with the code in this ticket and wants review from stakeholders or management.
- Two or more developers can’t agree on implementation details and neither of them will budge.
- For some teams, I’ve seen all of one developer’s tickets move to Blocked if they’re on vacation or sick leave. It’s up to you how you want to handle that scenario.
There are lots of ways tickets can get blocked; the important thing is that you stay on top of this list so your team doesn’t lose momentum. There are customisations available in Trello, Jira, and other ticketing systems that will flag or highlight tickets that sit in a particular status for too long; I’d suggest setting a flag for two or three days if a card sits here without an update or comment so you can see what’s getting movement and what’s sitting stagnant.
Done
Cards in the Done column meet the Definition of Done. That means the ticket is dev complete, it’s passed peer review, QA has given their stamp of approval and it’s ready to move down the deployment pipeline.
It’s nice to wait a week or two until there’s a sizeable chunk of stuff in this column before doing a review or product demo with your stakeholders. I perfer to do demos on an as-needed basis rather than on a regular set schedule – this helps prevent anything from getting rushed just to meet an arbitrary demo date, but your mileage may vary.
I want one!
I’m so glad you asked! I’ve shared versions of this project template with every team I’ve worked with and everything we’ve run through here is available for anybody with a Trello account to use. Creating a copy of the template for your own use is pretty easy to do and then you can modify it to suit the specific needs of your team.
Make sure you’re logged in to Trello, then on the upper right corner of the board click “Show Menu”, then “More”, then “Copy Board”. You can choose to duplicate the cards in the template (which I suggest doing) and then share your copy of the template with your team.
Have at it. 🙂
Comments are closed.