The Corrello Blog

Thoughts on Scrum and Agile with Trello

Page 2 of 2

How to add charts to Trello

Trello is great, but as a project management tool it can be a little bare bones. In this post we’ll look at a few ways you can add some different charts in to your Trello boards. The simplest is to get some existing plugins and power-ups to do the job for you. The next option is to use the API to add some totally custom charts that you can configure however you want (assuming you’ve the skills and the time).

Plugins and power ups to add charts to Trello

There are a bunch of different options here depending on your needs. We’ve got options for old school PMs looking for Gantt charts, agile teams looking for Burndown charts and Cumulative flow diagrams and for those of you who need to keep an eye on the time there’s great options around time tracking too.

Gantt charts

I’ll freely admit that Gantt charts are not my first port of call when looking to add charts to my projects. However, they serve a purpose and for some people they are the key chart that they need. The best place to get started adding Gantt charts to Trello is with a tool called Elegantt which works as a chrome plugin or a Trello power up (for business class users).


Elegantt also adds some nice features on top of Trello such as task dependencies and milestones (ie the date of an upcoming launch). If Gantt charts are your thing you should give it a go.

Scrum and Kanban charts

Naturally I would say this as I built it but if you’re looking to add charts for agile teams the best option is Corrello. It has a mix of features for both Scrum and Kanban teams, so you can get your sprint Burndown charts for your Scrums:


And for Kanban teams there’s Cumulative flow diagrams:


As well as Cycle time charts (and cycle time percentile ranges):


These and other charts are all available in Corrello, and for Trello business class users you can also install the Corrello power up to get the first two directly in your Trello boards.

The main alternatives to Corrello would be Burndown for Trello (here) for burndown charts and this site for CFD charts.

Time tracking charts

Harvest is a tool which gives you visual reporting to keep track of project progress and break down the hours that went into that project. It’s a great looking tool with plugins for a lot of project management tools including Trello. With their Chrome plugin or Trello power-up you can start and stop progress on individual cards directly from Trello. You can then keep track of the time spent on projects and tasks in Harvest. If you’re interested in tracking time spent and progress down to the hour against a time budget Harvest is a nice option.


Simple charts (counts of labels, overdue cards etc)

Sometimes all you want to know is how much work you and your team mates are getting done each week, and a few other simple counts (cards labeled as ‘bug’ or past their due date). This would actually be one of the simplest to build your own dashboard for if you wanted to use the API. If you’d rather someone else do it I’m going to have to plug Corrello again I’m afraid.


Using the API to create custom charts

I’ve written a little about creating your own dashboards using the Trello API previously. That should serve as a good starting point to get to grips with the API and put together a quick POC for your charts. The next step is to pick your visualisation library. For simple charts I’d suggest HighCharts which is what I use for all the charts in Corrello, and if you need some more complex charts check out d3.js.

An alternative approach if you want to avoid coding everything up yourself is to pull the data into google sheets. There is a write up on that approach here. That still requires some coding but it saves you creating the charts yourself as once your code has pulled the Trello data into google sheets you just manipulate it and create your charts there.


That’s it. My top picks for plugins again in case you wanted the links are

  1. Elegantt – for gantt charts
  2. Corrello – for agile charts
  3. Harvest – for detailed time tracking

Project (or Release) burnup charts for your Trello projects

I’m excited to announce the latest big addition to Corrello – Project (or Release) Burnup charts.

This is a new chart in Corrello which tracks to the total work in a project over time vs how much of that work has been completed.


The release burnup chart shows you three lines

  1. The red ‘total effort’ line plotting how much work has been in the release over time.
  2. The blue ‘completed’ line showing how much of that work has been done.
  3. The dashed blue ‘forecast’ line showing when you will be complete assuming your current velocity is maintained.

The total effort line is useful to visualise the impact of scope changes. If you’ve had to agree a load of new work as part of a project, this can be a nice way to show the impact of that on the schedule. The blue line then burns up towards that total as cards are completed over time and the dashed forecast line shows how things are expected to progress.

You also get some stats on how much work is remaining, your recent velocity, how long it will take to complete the work and how much of the work has been estimated. You can also drill down and see the individual remaining cards along with estimates of when they are likely to get done.

These charts can be enabled for any of your dashboards right now. If you have a Corrello account you can login here. If you don’t you can start a free trial here.


Burndowns and CFDs in your Trello boards – It’s the Corrello Power-Up!

Trello just announced their power-ups platform and here at Corrello we’re announcing our Corrello power-up for Trello. This is something we’ve been working on with the team at Trello since late last year, so it’s great to be able to talk about it at last!

The Corrello power-up is one of the first power-ups to be developed by someone other than the Trello team. It adds a Corrello button in the top right of your Trello board. Clicking on that gives you options to see a cumulative flow diagram, burndown chart or the full dashboard for that board. There are more details on enabling and using the power-up here.



I’ll be adding more features in future, let me know what you want to see.

How much automated testing is enough automated testing?

I had been a proponent of automated testing for a long time before we really adopted it at my last company. It was one of those things people wanted to do but never felt they had the time for. When we all actually started writing tests for our code was at the start of a new project, a rewrite of an existing product. The fact that on day one we could create and maintain 100% test coverage was a strong driver in writing more tests. I knew that code coverage was an imperfect metric, but it’s so easy to track it’s natural to use it. This is, I think, the key problem with automated testing that leads people to think that 100% is what they should be aiming for. When measuring coverage is so easy, and 100% coverage of your first piece of code is possible it’s natural to try and maintain that.

I think a lot of people who haven’t really considered what tests they should write also assume 100% coverage is what they should aim for. This seems to be the default opinion people come to the question with, if they even realise that there is a question to be asked.

Why 100% test coverage is actually a bad goal

I believe you should definitely not try to write “as much automation as possible” or fall into the common trap of thinking that 100% automation is an ideal to be aimed for.

Writing automated tests takes time, running them takes time and maintaining them takes time. Imagine for the sake of argument that only 50% of your tests are useful. In this case you have wasted time writing the remaining 50%. You need to wait for the other 50% to finish executing to get the results of the useful ones. And, you need to spend time maintaining them. Most of the work in software development is in the maintenance, not in originally creating the code. Less code is a laudable aim, this also applies to your tests.

So, you may well ask, how can we decide if we’ve written enough tests for a piece of code or not? Which is lucky because that’s what I’m going to tell you next :).

How to know if you’ve written enough tests

I propose splitting your tests into four groups:

  1. Core functionality of your app. If your app is a website monitoring tool then this would probably be any alerts which need to fire if a site has problems. If these go wrong your app isn’t serving its core purpose so having automated regression tests to run on every code change makes sense.
  2. The basics (often called a smoke test). For example you could use Selenium to click all the links to navigate through a web app and make sure the server responds with a 200 for each page. Note, I don’t mean checking the content of the pages, just that you can navigate the app and it’s not obviously broken. These tests ensure any manual testers aren’t having their time (and morale) wasted with obviously broken builds.
  3. Anything fragile which is likely to break. This is hard to define for new code, but if you’re working on some legacy code which you know to be bug prone then building tests around any changes you make is a good way to build towards being able to refactor more safely.
  4. Things the developers wanted to automate because it was easy to do. Sometimes it makes sense to add tests while you’re building something, that shouldn’t be discouraged.

By structuring your test cases along the above lines, when one fails people know why it was created. If it is the test that is wrong and not the code under test they should understand why it’s important to fix the test rather than delete/disable it. Or if it’s not important to maintain, they can delete it if that’s what they want to do. Note, I would suggest explicitly laying out your code using these four categories so anyone reading it knows which group the test is in.

Code review of the tests then becomes easier as someone can look at the functionality under test and form their own opinion about the tests which should appear in each category. This is where a code coverage report is useful, a scan through that as part of a code review may show something up which you think should be tested.

You can obviously adapt the above to your own needs, but I think the categories are vague enough they would suit most teams.

Agile team? Using Trello? You should check out Corrello – Dashboards for agile teams using Trello.

How to create recurring tasks in Trello

Update: If you are looking for a simple way to create recurring tasks and whole lot of other cool automation within Trello you should check out Butler bot.

Something I’ve seen over and over again is people creating recurring tasks in Trello. There’s a joke somewhere in that last sentence. Maybe not a good one admittedly, but it was only a short sentence.

There are a couple of manual work-arounds people adopt to deal with these situations. Let’s not worry about those, because today I’m going to show you how to automate recurring tasks in Trello. There are two versions of the story I’m going to tell. Firstly, the longer one for those of you who have 5 minutes to learn how to use If This Then That (IFTTT), and secondly a quicker one for those of you who just want to get your recurring tasks set up already and aren’t interested in any of my jibber jabber! Take pity on a fool and scroll down to the bottom if that’s you.

For both you’ll need an account on IFTTT, a free service which works as a kind of magical web glue for sticking your internets together. Clear? Fear not, it will be.

The long(er) version

Get an IFTTT account (free) by clicking the signup link on their homepage, which should take you here.

They will walk you briefly through how IFTTT works. It’s pretty simple. You pick two events, a this and a that. If this happens then we want that to happen. For example:

  • If ‘the weather is sunny’ (this)
  • Tweet ‘weather looks nice, let’s all go to the beach!’ (that)

Or in our instance, if the time is 9am on a Monday create a new card in Trello. Each of those is called a recipe by IFTTT.

So now you’re logged in, click on ‘My account’ and then ‘Create a recipe’ to get started. Or, you can go here which should do the same thing. You should see something like this


IFTTT has a bunch of what they call Channels which can trigger your recipes. Click on this and you will see some of them. Now, stop looking at all the channels and idly imagining the possibilities of wiring up every service you’ve ever heard of. We know we need the time channel, so type time in the search box and select ‘Date & Time’.


You now need to choose how frequently you want to create your new Trello card. Daily? Monthly? Annually? I’m sure you can work it out, you got this far!


I’m using the “Every day of the week at” trigger which doesn’t fire every day of the week, but every day of the week which you select. Ie, every Monday or every Tuesday and Friday.


Pick the time of day you want your trigger to fire on, and the days of the week (or whatever is appropriate for the frequency you selected) and click on create trigger.


We’re half way there! Click on that and search for the Trello channel.


When you click on Trello you will need to log in to your Trello account and let IFTTT access your boards. You will then need to choose which action you want to take in Trello when the trigger fires. Luckily there’s only one action…


So let’s choose ‘Create a card’.

From there you get to set which board and list to create your card in. Choose a title and description as well as assign members, add labels and link attachments. All pretty handy.

Finally you’ll be asked to confirm your choices and create your recipe. You should end up back on your My Recipes page and see your new recipe there. Now, just sit back, relax and wait for 9am Monday morning to roll around and your new robot overlord will tell you what to do :).

The quick version

Head over to IFTTT using one of these links, depending on the frequency of your recurring task

If you’ve got an IFTTT account sign in and add the relevant recipe. If not, click the signup link and follow the instructions.

Need a dashboard to keep on top of your Trello boards? Check out Corrello – Dashboards for Agile teams using Trello

Burndowns! CFDS! cycle time! label counts! all for Trello – It’s Corrello V2

I’m happy to announce a slew (is that the correct collective noun?) of new features in Corrello.

Trello is a popular tool for managing agile projects and it works great for the teams day to day work. However, it could be a bit better on the reporting side of things. The new features in Corrello V2 further close the gap between Trello and other Scrum/Kanban focussed project management tools. Here’s a look at some of the bigger ones.

For Scrum teams

Burndown charts

Choose which list holds your sprint backlog and you can get a burndown chart showing the ideal burdown vs how you’re currently progressing. Learn more about Corrello burndown charts for Trello or about Corrello for Scrum teams.


For Kanban teams

Cumulative flow diagrams

Does what it says on the tin. A cumulative flow diagram showing how many cards (or points) were in each list historically. Learn more about Corrello cumulative flow diagrams.


Cycle time scatter plots

A cycle time plot showing how long completed cards were in progress for vs they day they were completed. There is also a table showing cycle time percentiles. You can learn more about our Cycle time for Trello or all Kanban for Trello features on the main site.

cycle_time_scatter cycle_times

For everyone

Count story points or cards

Corrello now integrates with story point data from the popular Scrum for Trello plugin.

Stats on your labels

Get counts of bugs, important tasks or any other label important to you.


Backlog delivery date estimates

Need a rough delivery date for a card, or want to know how long the next version will take. You can now get all that by including your backlog in Corrello.


If you’ve not tried Corrello yet give it a go for free over at

Build your own Dashboard on the Trello API

Once upon a time someone created a Trello board and invited their team to it. Over time they added cards, moved old ones and archived those they’d finished. One day they started adding labels to their cards (‘Bug’, ‘High priority’, ‘Blocked’). Their use of Trello grew as the team grew, their project grew and others started using Trello. As the team’s use of Trello expanded, managers wanted to get updates on how the team was doing. Are we closing as many bugs as we opened? What’s our velocity? How about a cumulative flow diagram? There was much scratching of heads and “well I suppose we could…”. Until finally one intrepid developer took a look at the Trello API. You are that developer, and here is where you start building your first dashboard on the Trello API.

Wasn’t that a nice story? 🙂 It’s not too far from what I’ve seen at a lot of the companies I’ve been talking to while building Corrello – Dashboards for agile teams using Trello. Today we’re going to build a very simple dashboard which will show a count of cards with each label. The code is all available on Github but I’d encourage you to follow along as we build your dashboard here. It really is extremely simple, but it also shows the key concepts you need to learn about the Trello API to build anything you want on top of it.

First off – The Trello API

Trello have created a fantastic API. In fact, their own mobile apps are built against their API. They did this to show that they aren’t holding anything back from their public API. You get full access to everything their own apps do. You can make 100 requests every 10 seconds which is pretty good. We’ll be able to load the information we need for our dashboard without making people wait. If you were caching data locally obviously things would be even faster.

Trello have also published some very good Trello developer documentation which is worth bookmarking for future reference.

Our blank dashboard

If we’re going to have an empty dashboard, it may as well be a good looking one! So let’s get bootstrap. I’m using v3 but go with whatever you’re happy with. You will need to host this html file somehow. Use whatever you’re happiest with, we won’t be writing any back end code so it really doesn’t matter 🙂

Connecting to the API

Next we need to connect to the API and authenticate a user. The first thing to do is get your app key from here. We will need the key field in the next step where we add the client.js file from Trello to our dashboard, and authenticate our user.

If you look at where we are loading the client.js file from and you will see we pass in a parameter key=[AppKey]. Take [AppKey] and replace it with they key you got for your app.

If you reload your page you should be presented with this popup (if it doesn’t appear check that your browser isn’t blocking popups).

Authorize Trello API

This shows we’re asking for read permission only and that we want access forever. You can choose to get write permission as well when you call Trello.authorize(). Don’t worry, due the the magic of local storage you will only need to authenticate once 🙂

Selecting the board to report on

Now we’re authenticated we can access the Trello API as the user and start loading the data we want. We’ll start by loading all of their boards and asking the user to choose one for us to create a dashboard for. This is where things get a little more interesting.
There is now a select element which we will put our boards in and a loadBoards() function which gets the boards for the current user from the Trello API.

All the loadBoards() function does is call Trello.get() with the path we want to load and tell it to call loadedBoards() when it’s done. All resources in the Trello API are structured in the same way, so if you want to load a specific board you ask for ‘/boards/[id]’ where [id] is the id of the board you wish to load. To get the lists for a board you request ‘/boards/[id]/lists’. What we’re requesting here is all the boards the currently authenticated user can see ‘/members/me/boards’. Simple right?

Getting the counts for the labels

Not long to go now, but we’ve already connected to someone’s Trello account and loaded some data for them. Now we want to let them select a board to report on and get the labels for that board along with the counts of cards with each label. You’ve probably already guessed that we need to call ‘/boards/[id]/labels’ to get the labels we are interested in.

The JSON we get back from that request actually gives us all the information we need! Including the label name, how often it’s used and the colour to use.

Get the full final version of the code here.

What next?

That’s it. Your dashboard may not be anything too fancy (yet) but you now know how to get whatever data you want from the Trello API. If you want to check out the full documentation for the API head here, and if you want to see what is returned from any request checkout the sandbox. You could take your dashboard above and extend it to add the features you want, or move some of the code server side and start storing data in a database. It would be pretty simple to load the cards for a board and display the actual cards linked to each label if you wanted to.

Want a more advanced Dashboard?

If you’re looking for something more comprehensive without all the coding (where’s the fun in that?) do check out Corrello. It’s got cumulative flow diagrams, burndown charts, counts of bugs etc. and lots more.

Page 2 of 2

Powered by WordPress & Theme by Anders Norén