Creating a Definition of Done

Today in our project planning sessions we discussed the idea of a Definition of Done. Now this is the first agile project I’ve worked on where we’ve actually defined what we, as a team, think a definition of done is.

As a developer I can really see the benefit that having a DoD set out from the beginning has. It gives us a checklist to go through when we have finished a task so we know that we can ‘officially’ say it’s done.

I think for 2 main reasons why the DoD is important for a developer, one that I can be happy to say that I have done/finished a tasks when I have met all the criteria that the DoD has set out. The second reason I think having a DoD is important for developers is that the quality of the project stays at a higher level as the project goes along.

If your Definition of Done says that a task can only be finish if it has 100% code coverage and has been checked over by a designer to make sure the work matches what they have designed. Then the quality of the project remains at a consistant high level, because you can’t say something is finished until all the quality checks have been made.

2016 – Wasn’t to bad

2016 wasn’t too bad for me, considering that a few years ago around this time I had just got out of hospital, I had blood clots in my legs and a kidney that hardly worked.

2016 started with me getting 2 Ionic freelance projects. I’ve always wanted to go 100% freelance specialising in Ionic mobile development. So getting 2 projects at the start of 2016 was a great start.

Unfortunately the bad side of freelancing soon followed after these two projects finished. Late paying clients, and no other work on the horizon meant that my freelancing ‘dream’ soon died as I had bills to pay and no income.

So I went back to contracting. I spent about 4-6 weeks in mid-2016 looking for a new contract, eventually I got a new contract in central London, but unfortunately it was a terrible contract and I left 4 days after starting.

The people I was working for were working in a terrible way, they had all their developers in one small room, with Project Managers asking for updates every 5 mins. There was no sprint planning or anything in the way of good development practices. I had a bad feeling about the place after one day, so I was glad to be out of there as soon as I could.

This did mean I still had a few more weeks without being paid. Thankfully some of the late payments from my freelance work came through so that helped.

Eventually I got a new contract working for a great company, building their new Angular based website. As part of the team we managed to get the new version of the site out, but then went straight into a long cycle of bug fixing.

Generally bug fixing can be fun, it’s a challenge to find the cause of the problem, then working on a way to fix the issue. But 5 months of solid bug fixing meant I wanted to look for something new.

So now I’m working on a large Angular 1.5 project for a well known brand, when the site’s live I’ll be posting who they are. This is my first project using the new Angular 1.5 components based approach, which I really like. Being able to moduralise everything, making everything a separate component is a challenge to get started (especially unit testing components), but once past this using components seems like it is the best way to build apps. Lookign forward to getting into Angular 2 very soon.


So 2016 was alright, a couple of hickups with late payments and taking on a terrible contract, but the end of the year has got a lot better.

My plans for 2017 are continue on this large contract (which should take me to mid-2017) I’m also planning to build a Ionic 2 app as a side-project in order to learn Angular 2 and hopefully get some Ionic work towards the end of the year.