How to set up a new Trello board¶
At Beautiful Canoe, we use Trello for client-facing documentation, particularly in the form of Kanban boards.
Always avoid using technical words, or software development jargon on Trello boards. Each card on the board should be written in a language that the client or an end-user will understand.
We have a standard-set of lists that each new project should start with. This is more complex than a standard Kanban, because we want to make it clear to the client when a card is waiting on them for testing or more information, and when a card is waiting on us. Some boards will have extra lists, as appropriate to the project, but each Trello board should start with this standard set of lists:
- User stories or you might call this feature requests.
- Bug fixes
- In progress should be regularly updated at each sprint planning session, so that clients can see what has been scheduled for the current sprint.
- Completed but not on staging server this usually means work that has been merged into
developbut is not yet on a release branch.
- On staging server and waiting for sign-off from client this is work that is on a feature branch, and waiting on user acceptance testing (UAT).
- Signed off by client and waiting to deploy to production server this is work that is on a feature branch and has passed UAT.
- Completed and deployed to production i.e. general acceptance (GA).
And you should also add this set of labels:
- Is fully specified on GitLab Kanban means the card has a related issue on GitLab, which has been fully specified with a definition of done. The GitLab issue should be linked somewhere on the Trello card (either in the description or in a comment).
- GitLab Kanban needs more detail means that there is a linked issue on GitLab, but it needs more detail before it can be scheduled and assigned to a developer.
- Waiting on BC for GitLab Kanban to be updated means that we have not yet created a GitLab issue for this card.
- Needs more detail from client means that this card should be discussed in a client meeting, before any more action can be taken.
- Required for next version means that the feature request should be scheduled in an upcoming sprint.
You can see an example client project here.
Using the board¶
Once the board has been created, it will need to be regularly updated. This will mostly happen in sprint planning and before or during client meetings, although ideally boards will be updated whenever a merge request is merged. Each card on the board should have enough information for the Scrum Master to be able to create a complete use case or bug report, remembering that the card should be written in the language of the product, and understandable to an end-user.
You might use the following templates, which are based on our templates for GitLab issues:
A template for user stories¶
## User story **As a** **I want to** **So that** ### Scenario **Given that** **When I** **The system will** **And then** **And then system** ...
A template for bug reports¶
## What is the current *bug* behaviour? What is the current, incorrect, behaviour? ## Steps to reproduce the bug How can a developer or user reproduce the issue? Please provide detailed steps: 1. Step 1 1. step 2 1. You get it... ## What is the expected *correct* behaviour? What should happen, when the bug is fixed?