The Corrello Blog

Thoughts on Scrum and Agile with Trello

Communicating team performance to your boss

Measuring the performance of a development team is notoriously difficult. People have tried using lines of code, function points and other more complex measures. Some still rely on tracking the hours developers spend in the office as the key measure of value produced :). Even when you trust everyone is working their best it is still a struggle to see if a team is more or less productive one month to the next, because they never produce the same thing twice. Yet we’d still like to know, and so would those we report to.

Today we will look at two pieces of data and how to explain those to your boss so they can see the improving (or consistently high) performance your team is achieving.

Using cycle time to explain improvements to your boss

Take a look at these figures from the previous post about removing bottlenecks in our process.


The total time in progress here shows that if your boss asks how long a random card will take you can tell them with 50% certainty that it will be done in a week. Maybe they want to be more certain than a coin toss that you will deliver on time? In that case you will need to estimate 1 ½ months to get to 95% certainty!

Now imagine in 6 months time if after a lot of work and improvement our numbers look like this


Now we can tell our boss that if they pick a random card and ask how long it will take to complete you can be 95% certain it will be completed in 2 weeks or less. On top of that, half of the cards worked on get completed in under 2 days.

Now your boss may think they can get work done this fast already, the point here is that these times are delivered by the team without any disruption to their process. It is possible now that boss requests are expedited at the cost of other tasks. No one really wants that.

Explaining things like this is something people outside of development teams can often appreciate. Knowing they can ask for something to be done and have a high level of certainty it can be delivered 2 weeks later without it disrupting the teams work is good to know. I am sure your boss would agree that going from nearly 7 weeks to deliver something to 2 weeks would make a huge difference to the businesses ability to deliver work on time and react to changes. That might be a good time to bring up your team’s next bonus :)

Obviously there could questions around relative card size or complexity. While it could be that the team is working on smaller tasks (no bad thing in itself) there is a limit to how far those improvements can go. This is where the CFD comes in, to help show how we got these improvements.

Using the CFD to show your process improvements

Let’s look at two CFDs. This first one which suggests a few things we should look to improve in our process.


What we can see here are frequent buildups of work in various parts of our process. A few questions spring to mind here, e.g. does code review always need to take so long? The same could be asked of the ‘Ready for deploy’ list.

Now if we take that as the before picture you can show your boss, here is the after picture some months down the line.


Here we have done three things:

1. Reduced the number of cards in the code review and ready for deploy lists.

This is probably one of the most impactful changes in this CFD. If you tell people that you now get work done 3x as fast as before they may not believe it. Yet if you show them that time spent on these cards previously was mostly spent waiting in these lists, and that you have reduced that time down they can see how it was achieved. By getting cards out of those lists faster you have sped up the whole process end to end.

2. Dramatically reduced the scale of the buildups of work in all of the lists

Reducing the scale of buildups should be understood as a good thing since it means people are not getting overloaded with too much work as those lumps work their way through the system. This has an impact both on quality and the ability for cards to get quickly through the process.

3. Reduced the amount of work in progress in total

Finally, by reducing the total amount of work in progress you let the team focus on delivering a smaller amount of work all at once. Rather than context switching and trying to focus on too many things at the same time. This again allows them to get cards completed faster.

To summarise, showing improved performance with Corrello comes down to

  1. Showing that the average time from starting work on a card to completing it has been reduced. And that you can now say with 95% certainty for some randomly selected card that it will be done in X days.
  2. Showing how those changes came about with the change in the CFD chart.

It’s still a little technical, but it’s backed up with actual data about your team. Hopefully it gets the message across that these improvements are real. And, once you have the performance you want it is still useful to be able to show these numbers and charts as evidence things continue to work well.

If you’ve read this far and you’ve not got a Corrello account you should try out our 14 day FREE trial.

 

Using cycle time and a cumulative flow diagram to get more work done by eliminating the bottlenecks in your process

Today I want to share something successful teams do to improve their process and get more work done, delivering projects on time and making their clients and bosses happier :). You don’t need to be using Corrello to benefit from this post but you will need to know your cycle times and have a CFD for your process. If you’re using Trello why not get a 14 day free trial of Corrello and check out your numbers.

We will be looking at two things in Corrello, the cumulative flow diagram and the cycle time numbers. What we are looking for is bottlenecks in your process. Once you have a good idea of where they are I will show you how to communicate them to your team so they can see and fix them.

First stop – Cycle time stats

Here we see the cycle time stats for a pretty typical development team where tasks are coded, code reviewed, tested and then moved to done.

email-bottlenecks-cycletime-lists

The numbers we are interested in here are in the second table showing the time spent in each list. If you don’t currently split your in progress lists up for each step in your process you may want to make the change so you can get this information.

We will focus on the code review column here which shows that

  • 50% of the time we code review a card in 2 days or less
  • 85% of the time it takes 3 days or less
  • 95% of the time it takes up to 16 days!

The question to ask is when we spend 2 days or more in code review, is that because we’re being super careful about code quality and making sure everything is perfect? Or, is it because cards are waiting to be code reviewed for 2 days before someone finally takes the time to check it over? I think we all know the answer. Asking your team will likely elicit the same response. We are all in the business of delivering working code to our customers, so something which has been started already should be pushed through the system before we start something new. Task your team with getting this number down and you will see your whole process improve as cards a delivered sooner.

Obviously the list or lists you will choose to focus on will be unique to you. I would only suggest picking one and tasking your team with improving that before tackling the next one. Rather than risk weighing them down with multiple improvements all at once.

Second place to look – the Cumulative Flow Diagram

Here we have the cumulative flow diagram for the same team, currently only showing the work in progress lists.

email-bottlenecks-cfd-wip

What we can see here are the same details we have above but without the specifics about how long cards are spending in these lists. We can see that the code review list generally has 3 to 5 cards in it each day. That means 3 to 5 cards were in the list for at least one day. If we were to drive down the amount of time cards spent in code review we should see that green segment shrink down and quite likely disappear altogether.

This is often the best way to show the data to your team. The aim for them then is to reduce the size of the green line. Which simply means reducing the amount of cards in the code review list. Those are simpler steps to take than ‘trying to do code review faster’ although they have the same effect. It is also easy to see the improvement day by day on the CFD. If you use Slack you can install the Corrello Slack app to show your team the improving CFD chart each day.

Next steps

Hopefully you have another minute or two? If so, you should…

  • Log in to Corrello and open your dashboard (or start a free trial if you aren’t already using Corrello)
  • Take a look at the history tab to see if you can identify a list you want your team to focus on
  • Take screenshots of the CFD and jot down the cycle times to show to your team
  • Decide when you will talk to your team about the improvements you would like to see

That’s it for today. Next week we will look at what a healthy CFD and cycle time chart look like. After that we will tackle the tricky issue of communicating team performance to your boss.

New ACTIONABLE email reports for your Trello boards help improve your team performance

OK, I’ll admit it. The old email reports Corrello sent out were rubbish :(

Especially compared to the new ones! :) If you want analytics and reporting to help you improve your team performance delivered direct to your inbox you’ll love the new email reports.

For those of you sprinting you will see your latest burndown chart, the trend for how much work was left at the end of the last 3 sprints and how much work was added or removed from those sprints. You can use this to look for trends, such as

  • Are you regularly leaving a lot of work uncompleted at the end of each sprint? Perhaps you are over committing when sprint planning
  • Is work regularly added into the sprints? This could be putting pressure on your teams, maybe you need to push back more on unplanned work coming into the sprint.

There is also information on

  • Which cards took the longest to complete recently
  • What your Cycle time trends are looking like
  • Your recent work in progress trends

As well as the last 3 weeks (or sprints) trend for all the stats you’ve asked Corrello to track for you.

Not got a Corrello account? Join the free trial and start improving your team performance this week.

 

What labels are in your Trello backlog and how long will it take to complete those cards?

The latest (small) update to Corrello adds the ability to see what cards are in your backlog based on both the list they are in and the labels they have assigned.

backlog_lists_labels

For the labels you can see how many cards with each label are on the backlog, how many are currently in progress and an estimat of how long it would take to complete them all. This can be especially useful if you use labels in Trello to group cards into Epics (or other collections of cards). This way you can see how long it would take to complete an individual Epic assuming you focused the efforts of the team on that one piece of work.

For the lists you can see how many cards are in each and an estimate of how long it will take to complete all the cards in that list assuming you focused all your efforts on completing those cards. This can be useful for Kanban teams so you can be sure you have enough work ready for the team to work on, as well as an estimate of the size of the outstanding backlog. If you are using lists to store upcoming releases this also gives an idea of how long it will take to complete each upcoming release, particularly useful in combination with the project burnup charts in Corrello.

You can check out the new features in your dashboards here. If you don’t have a Corrello account you can check out all the features and try out our 14 day free trial here.

In the screenshot above we are reporting estimates in terms of cards and sprints to complete the work. For Kanban teams this would be shown in weeks and for teams using Story points this would be reported in terms of points rather than cards.

This is the second addition to the backlog tab in recent months, after the inclusion of the Burnup charts previously. There should be more improvements coming here in future, if you have suggestions please do comment below or drop us an email :)

Slack + Trello + Corrello = Trello Burndowns, CFDs and stats in your Slack Channels

Corrello + Slack = Burndowns, CFDs and Stats for your Trello boards in Slack

Apologies for the long title, there’s a lot of services getting tied together in this update!

I just launched the Corrello Slack app, you can try it out here. If you’re not familiar with Corrello, it’s a dashboard for agile teams using Trello. You can use it to see Burndown charts, release forecasts, cumulative flow diagrams, cycle time and much more for your Trello boards. The Corrello Slack app gives you access to some of those features directly in your Slack channels.

The Corrello Slack app adds these three commands to your Slack channels:

/burndown

burndown_small

The burndown command lets you get the latest burndown chart from one of your Corrello dashboards. This is the burndown for the current sprint as is visible to everyone in the channel, great for standups!

/cfd

cfd_small

The /cfd command shows you the last 2 weeks from the Cumulative flow diagram for one of your dashboards. Clicking the link in the title takes you to the full CFD where you can choose what date range you want and turn lists on and off.

/stats

stats_small

The stats command pulls the stats for the latest sprint (or week, if you’re not using sprints) for one of your dashboards. These are all color coded the same as they are in Corrello, clicking on them takes you directly to the list of matching cards. The stats displayed are the ones you have set up for that dashboard, they can include counts of cards (or points if you’re using them) completed, due, overdue or with specific labels (ie ‘bugs’).

That’s all folks! If you’ve already got a Corrello account you can add the Slack app here here. If you don’t have an account yet you can sign up for a free trial here.

$0 to $1k MRR in 57 months

Late last year I finally passed the (at least psychologically) significant $1k MRR mark on a business I’d bootstrapped solo. Since then things have picked up even more but I wanted to go back and write this post about the journey from $0 to $1k.

In case it’s not obvious from the title, this isn’t one of those exciting “I built something in a weekend, launched it and paying customers rained from the skies” posts. Not to malign those, I enjoy them as much as the next guy. But, that’s not been my experience or the experience of anyone else I know. This post is about the journey over 4 years to go from launching ideas that had little chance of success, to launching Corrello (Dashboards for agile teams using Trello, if that’s you check it out :)) which is showing some signs of being a success. I wanted to write something for those of us who struggled to level up their skills and knowledge by failing over and over. I want to focus on what I learned in the 4 years before I started work on my latest venture, not on the tactics I’ve learned since. Because I think there is value on those lessons, and without learning those I wouldn’t have got to $1000 MRR and beyond. I’m not going to cover everything, just the highlights. And I’ll try to keep things succinct. If you’re a software developer or budding entrepreneur who wants to launch their own software product there should be value in the story below.

57 months to go – JobsTractor.com

I registered the domain name JobsTractor.com on March 11th 2011. Jobs Tractor got taken down last March and never made me any money. That was the first time I actually launched one of my side projects so I’m taking that as the slightly arbitrary start date of my journey to $1000 MRR.

I started Jobs Tractor with a simple idea “Top blogs like Joel on Software etc. make good money advertising jobs, so what if a load of smaller sites ganged together and did the same?”. The plan was to offer an alternative to advertising, and by aggregating readers from multiple blogs we could reach a similar audience to those larger sites. I built the site out, including heavy load testing of the endpoints which would be used to get the jobs to display on people’s blogs. I think I actually built some stuff to get the most relevant jobs based on the user’s location from their IP address. Obviously I had all the user admin, the ability to post and edit jobs and paypal (bleargh!) integrated to take payments. I also had to learn how to host and deploy everything as this was the first side project I’d actually put out into the wild. All this took several months of evenings and weekends. I honestly can’t remember what I did to ‘launch’ the site, I probably just put it up and posted it to HN. No one came, no one cared.

Whilst building Jobs Tractor I’d come across a couple similar services which had closed their doors or pivoted some time ago. One still had a list of the blogs they published jobs on. I started looking for contact details and emailing the people behind those blogs. The bloggers who got back to me told me that the service never really worked for them and that they did a lot better from advertising anyway. Which put an end to that whole plan! That was the last time I invested that much effort in something without getting some feedback on the idea first. Memories of weekends sat at home working while my friends (and girlfriend, now wife) were out somewhere nice in the sun inoculated me against building too much functionality without first getting some input from potential users.

A few months later I was messing around with Mongo, Node and the Twitter API, trying to find what programming languages people were hiring for near me. I had a simple search to get tweets which looked like job posts, filtered out jobs boards and recruiters, did some simple classification to remove tweets which weren’t jobs and worked out where the job was based and the programming languages involved. This turned out to be a potentially useful way of finding people hiring developers directly via twitter (minus the recruiters and job boards spam) so I incorporated some Javascript which would identify where a user was geographically, and then had the site load the most recently posted jobs close to them. I posted this new site to HN, hit the top of the front page for several hours and had to have a serious sit down to relax myself! I’d included the ability for people to give me their email addresses in return for a weekly email with jobs for their location. Having learned my lesson about writing code no one was going to execute I’d not actually written anything to send the emails out. I spent the weekend happily hacking that together in time for the first batch of emails to go out on Monday.

Next I started emailing news sites trying to get some coverage for Jobs Tractor. This was hard work at first and I spent far too long hemming and hawwing before sending each email. It’s strange to think how shy/nervous I was about sending those emails back then. But you only get past that sort of roadblock by doing the thing you’re nervous about and I can honestly say it’s not something which gives me pause for thought nowadays. Lesson learned here? If something needs to be done but feels unnatural just find a way to get it done. Repeated exposure will make it easier over time.

I spent odd bits of time over the next couple of years trying to get some revenue from Jobs Tractor. At first I thought the users I had would be useful in attracting employers but in reality I had probably one or two people in dozens of cities around the world so any employer trying to post a job was unlikely to find someone local with the skills they needed. Possibly I could have picked a location which I seemed to have a lot of devs in and focus my efforts there, including a lot of personal out reach to employers. This may have worked but I wasn’t ready for that kind of approach at the time.

Jobs Tractor remained up and working until early last year when I decided to kill it to save load on my server. I learned a few things from the experience, but the main takeaway for me (apart from not wasting time on code no one will use) was to build something people can get utility from without needing to have other people on the site. What I’d built was a two sided market place. If you’re no good at marketing, a two sided market place just means you shot yourself in the foot twice. Two sided market place ideas always sounds great at first, and once you’re at scale the are. But to get there you need to attract each side of the market. And just because you have one side doesn’t mean the other side will magically appear. You still need to tell them about it. Beware ideas which only sound interesting once you’ve got 1000s of users on your site, unless you have a clear plan on how to get those early 1000s interested.

42 Months to go – WordSearchGenerator.org

The rules so far:

  1. Don’t spend ages building a load of highly polished functionality no one will ever see.
  2. Build something user 1 can pay for and get use from without needing other people on the site.

You may well have heard of Patrick McKenzie and his original business selling bingo cards to school teachers. Well, I did some googling and checked search volumes for a similar niche selling software which would generate word searches. It seemed OKish, with a bunch of crappy sites, some reasonable search volume and low competition on those keywords. I put up a site using a landing page generator, when users clicked the buy button they went through to a form which said we were coming soon and asked for an email address. This collected a bunch of email addresses and convinced me it was worth pushing ahead. I wish I could remember numbers here but I can’t so just trust me it seemed like it might be a sensible idea, although I was probably willing it to be if I’m honest. The site didn’t take long to build and looked like it was from sometime slightly after the late 90’s, I was pretty pleased with it! I deployed it, fired up adwords and started thinking about content marketing and SEO. In the end I ran it for a while without getting any actual paid customers. People were checking it out but didn’t want to pay when I asked them to subscribe to the service. I dropped the price, and dropped it again. In the end I was almost giving it away ($19 lifetime subscription) , and even if I could get a few signups it was going to be a long way off being a significant amount of monthly revenue.

What did I learn here? This was one of many small sites I built and deployed fairly quickly. Ultimately I learned I wanted to build a SaaS rather than go after one off sales, and that I needed to target people who had a problem big enough they were going to pay serious money ($30/month or more) to have it solved. I also learned something (but not enough) about contacting your early users. I collected those first batch of email addresses but did nothing to get in contact with them until I launched.

22 Months to go – HuliMail.com

The rules:

  1. Don’t spend ages building a load of perfect functionality no one will ever see
  2. Build something user 1 can pay for and get use from without needing other people on the site
  3. Build something worth $30/month or more

Hulimail came to me while reading up on marketing technologies. In the preceding few years I’d started to develop an interest in marketing (if not any real skills). I was reading an article on the FullContact blog one night about how Maptia had jerryrigged something to send them an email with research on new signups to their prelaunch mailing list. The following day I was up early, coding for 12 hours straight (happy pre-parenthood times when I had 12 straight hours free on a Saturday :)). On Sunday I decided to rein myself in from coding too much before some validation and focused on getting a landing page up instead. I started collecting email addresses and posted the site to betalist. Someone also posted the pre-launch site to ProductHunt which got me another 100 or so email addresses.

As I built I posted updates to the mailing list and heard back from people occasionally. I started onboarding people individually but didn’t really get anyone that interested in the solution I was offering. I did get a few people signing up but for the most part they were interested in free access in return for ‘help developing the product’ or in one case some actual promotion to their sizeable audience. I took these offers as I wasn’t really a user of the tool myself and felt I needed people’s feedback. In retrospect I should have pushed for people to pay, and if they weren’t willing I should have looked for someone who was. Not doing so early on let me keep working on something which I think ultimately didn’t have a market I could find economically.

If I learned a lesson here it was about validation, and that people wanting to use your software for free isn’t enough (it’s something, just not enough). The interest in Hulimail wasn’t from people with a problem they desperately needed solving, but something they’d like solved if it was cheap/free to do so. I also learned to consider the market. The people interested in Hulimail were mostly trying to avoid spending money somewhere else, this doesn’t make for a lucrative customer base.

10 Months to go – Corrello

The rules:

  1. Don’t spend ages building a load of perfect functionality no one will ever see
  2. Build something user 1 can pay for and get use from without needing other people on the site
  3. Build something worth $30/month or more
  4. Build something to solve a problem people are willing to pay for
  5. Charge early, and beware products aimed at people resistant to paying for things

I won’t say much about building Corrello, except that I think the final piece of the puzzle fell into place when I had a chance conversation with Josh Pigford (of BareMetrics fame) briefly after launching my MVP. He pushed me to contact everyone who had signed up and to have a conversation with them to understand what problems they were having with reporting from Trello. Rather than assume I knew what I should build I should start by finding out as many people’s problems as possible. This was something which was missing from my previous efforts. I’d always considered the pre-launch mailing list as a group of people interested in what I was building. Instead, I started to view them as people with problems in roughly the area I was working in, who I should talk to and understand those problems so I can decide exactly what to build. This led to a change of direction and ultimately a fairly well defined market to go after. This is an important lesson for a lot of entrepreneurs I think as it’s easy to fall in love with your idea. You need to talk to anyone interested enough to give you their time and find out what their problems actually are.

If you’d like to hear more about my journey over the last year you should check out my interview on the excellent Britstrapped podcast.

Conclusion

The rules (for me YMMV):

  1. Don’t spend ages building a load of perfect functionality no one will ever see
  2. Build something user 1 can pay for and get use from without needing other people on the site
  3. Build something worth $30/month or more
  4. Build something to solve a problem people are willing to pay for
  5. Charge early, and beware products aimed at people resistant to paying for things
  6. Your pre-launch list (and early customers) are probably interested in something other than (but close to) what you are building. Success comes from finding out what that is

It’s been a fun/hard/exciting/depressing few years working on this stuff. It’s been a slog at times, but I’m glad I did it. I don’t think you can really succeed at anything meaningful without failing a bunch first. If you’re in a similar place to where I was, keep at it and try to make sure you don’t make the same mistake twice.

The only other thing I’d say is that if you’re on an agile team using Trello you should check out Corrello :).

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

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:

Trello-Corrello-Sprint-Burndown

And for Kanban teams there’s Cumulative flow diagrams:

cfd

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

cycle_time_scatter

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.

harvest

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.

performance_history

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.

burnup

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.

Trello-Corrello-CFD

Trello-Corrello-Sprint-Burndown

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.

Page 1 of 2

Powered by WordPress & Theme by Anders Norén