2018 04 30 19 06 32
May 24, 2018

Revolutionise your software development lifecycle with Trello (Part 3/4)

Evan Golden 5 minute read

Welcome to the third installment of a four-part blog series where we focus on using Trello, a lightweight, and easy to configure tool, to manage and simplify your software development lifecycle (SDLC).

In part 1 we covered how to use Trello to manage feature requests, answering key questions like: 

  • How do you collect features from our customers?
  • How do you identify what features are most important to customers?
  • How do you make decisions as to what features will be selected for development?

In part 2 we covered how to manage requirements, discussing items like:

  • Managing epics and stories
  • Dependency mapping
  • Estimation
  • Ranking

Here in part 3, we are going to focus on development teams.  Now that we have our features, and have built out our epics and stories, our teams need to know what to work on next.  In this post, we will cover the following topics:

  • Assigning requirements to the development team
  • Managing sprint planning and execution
  • Closing a sprint
  • Retrospectives
  • Kanban teams

Assigning requirements

Our development teams are like a moving train.  When they are passionate about what they are building, they can keep going and going.  At Adaptavist, we create some of the best products in the marketplace, and that is because our development teams can use their creative skills to the max.

Our Product Owners help the teams prioritise the backlog, so customers continue to get amazing features.  So the question is, how do you transition a requirement from a planning board to a place where teams can work on it directly?

In part 1, we discussed our feature board, where our features are received and triaged.  From there our features need to be decomposed into stories.  

The board below is what I call the "team board."


Notice on the far left there is a "features" column.  When a new product feature is approved, I like to move it from the feature board to our team board.  Next, we decompose this feature into pieces of work for our development team(s).  For this I use the helloepic power-up to create the stories and link them to the features.  During creation, I put them directly in the "backlog" list on my team board.


Once all of my stories are in my backlog, they are ready for prioritization, and estimation.  Next, let's chat about how our scrum teams can work on the team board.

Complete traceability

On our team board, you will notice that there is a 'To do' column.  We estimate all of our stories in the backlog column, and during sprint planning, the scrum team will move stories from the top of the backlog into the 'To do' column.  Well that depends.  

First, what is our historical velocity?  This information will help to determine how many story points, on average, we can complete per sprint.  As the stories are estimated in the backlog, we can just add stories that total as close to our velocity as possible.  

See the snapshot below.  If our velocity is 20 points, and we are planning our sprint, then we move the stories in order into the 'To do' column.  You may notice I decided to move over 19 points worth of stories.  This is because we estimate the next story to be 2 points, which would take us to 21 points.


For the execution of our sprint, we work within our 1-4 week sprint time box, moving stories from 'To do' to 'In progress,' then to 'Test', and when completed, 'Done'. Workflows may vary, and that is fine.  Adjust your lists as required to suit the needs of your team.


What I like about the team board is that it gives the entire team complete traceability on one board, from the Product Owners to the Developers. Anyone can view the features in order of priority.  The backlog ranks all the stories, and you can view all the activities and tasks in the sprint columns.

At the end of our sprint, we will have a product increment.  This may or may not be released.  Our next part of this blog series and the final part will be on how to do release management in Trello.  This will include how to manage product increments that are not ready for release.

Creating retrospectives

Historically I have managed the majority of team meetings in Confluence.  I have even used tools like Smartdraw for Confluence to record my meeting notes.  I have since discovered, however, that Trello is a fantastic tool to record my meeting notes.

Below is an example of a retrospective board on Trello.


Every list is a retrospective which represents a meeting date.  Here we have a card for our major topics in a retrospective.  When it is time for the next retrospective, simply add a new list, or copy the previous list, and change the date!

Trello for Kanban

For Kanban teams the process is quite simple.  Remember our board?


Instead of using sprints, our Kanban team will just keep working from the backlog without using a time-box. The same visibility is available to all our teams from the initial feature request, to the requirements to the release management (which will be covered in part 4).  So you might be asking yourself, what about 'Work in Progress (WIP)' limits?  There are two ways to do this.  Teams can put the WIP limits in the headers like in the example below.


The other option is to use a power-up.  Remember our power-up from part 1 called Agile Tools by Corrello?  This tool can also configure WIP limits for our board.  

Just go to your power-up settings like below, and select "Setup WIP limits".


From there configure your desired WIP limits, and click "save". Be sure to also check the box to enable WIP limits.


Now on your board, you will see the WIP limits in each card of the 'In progress' and 'Test' columns. (ie: 2/6 and 1/4).


Stay-tuned for our final blog in the series, part 4!

In this post, we explored how scrum and kanban teams can work within Trello to plan and execute their story development.  We covered how to assign requirements to the team on the team board.  We also described how to plan a sprint, execute a sprint, and create retrospectives.  And finally we showed how kanban teams can also use Trello.  

Join us again for the final blog in this series, Part 4, where we will share how you can use Trello for planning, scheduling and controlling your software build through release management.