Skip to content

Words and Stuff

random ramblings

Tag Archives: process

* that we’ve figured out.

First setup one board.

In that board build the following lists:

  • Backlog
  • In Development
  • Development Complete
  • Ready To Test
  • In Test
  • Complete

Put any features/bugs/enhancements into Backlog.  As developers pick the card, they should assign themselves (if not previously assigned) and move it to In Development.  Once development is complete and unit tested, move the card to Development Complete.

Once the code is to a good point to test, migrate the code to the test environment and migrate all cards in Development Complete to Ready to Test.  The testing team then moves the cards from there to In Test.  If the test passes, the card moves to Complete, otherwise it moves back to Backlog with a comment as to why it failed testing.

Once a release is scheduled, build a new list “Release x.x.x MM/dd/yyyy”, release the code and move all cards from Complete to that release list.


If your project is sufficiently large (ie your backlog is unwieldy or your have had a number of prior releases), you’ll likely need two additional boards.  The first board will be your Product Backlog with lists based on priority, feature type or any other structure you need. You’ll use this board to determine what goes into your sprint/next release/unit of work.  The second board is prior releases where you’ll migrate the “Release” lists of completed cards to after the release is complete.

Luckily Trello makes it easy to move cards from one list to another and from one board to another (and to move entire lists from one board to another) so the process of moving these cards is not onerous.


This setup has worked well for us for single developer releases, project with a multi-hundred card backlog and projects with 4-6 developers.  Our process is fairly fluid and flexible, so this system works well for us, but might not work for your team, YMMV, etc.

Advertisements

Tags: , , ,