book a demo

17
Feb

2017

Thinking Agile: What does 'Done' really mean?

One of the cornerstones of the SCRUM framework, the concept of a 'Definition of Done', is often neglected. This can easily lead to seemingly half-finished and buggy features being released to production. A clear Definition of Done can help a development team to avoid these pitfalls by ensuring a common understanding of what is expected from production-ready code.

Why do we need a Definition of Done?

In Agile methodologies, there is often an emphasis on getting new features into the hands of users as quickly as possible. This is a meritable aim – the features that we as software developers build are there for these users, so seeing them in use is valuable for many reasons.   

It gives reassurance that features are being built for some purpose, it provides quick feedback on the details of the implementation, and above all, it offers increased value to the users themselves. However, this 'need for speed' can come with serious risks: if proper controls are not put in place, the code can be rushed into production with bugs or regressions. Certainly ,there is no increased value to users in that scenario! 

To avoid this, the SCRUM framework suggests the use of a Definition of Done, which it defines as A checklist of valuable activities required to produce software. 

In other words, it is a list of all the steps through which a user story, and its associated code, should have passed in order for the finished functionality to be safely shipped to production. 

Building a Definition of Done

At first glance, this may seem simple: code needs to be complete, and the functionality needs to be tested. However, if we begin to break these items into more detail, it can quickly become a very large list. Looking to a traditional Waterfall project for inspiration, the full list of validation activities might look something like:

  • Functional spec written & signed off, technical spec written & signed off
  • Code written, peer reviewed & signed off
  • Unit tested, integration tested, QA tested, UATed and regression tested

Not an insignificant list by any means. And one which involves a lot of different people, traditionally over an extended period of time. How, therefore, can we translate this to a SCRUM approach, where we aim to achieve this in a 1-4 week sprint?

The reality is that, even when we apply Agile principles to strip this list back to its essentials, a number of people from different backgrounds, both internally and from clients, will need to be involved, and it is not always possible for this to happen within the timeframe of a single sprint.

Multiple Definitions of Done

For this reason, the approach that we at AgilityWorks have adopted is one of the multiple levels of 'Done':

  • Sprint 'Done': the story is completed as far as is possible within the scope of a sprint.
  • Release 'Done': the story is ready for shipping to production.

The exact details of these definitions will vary from project to project, and it may be that there are additional Definitions of Done, but this basic framework allows a level of flexibility and compromise to be built into the process. It is accepted that it's not always possible to release code to production at the end of each sprint, but there is still a concerted effort to get it as close as is realistically possible to this point. There should still be tangible outputs, visible to stakeholders, at the end of each sprint, and ideally, these should be shippable to, for example, a test environment. But, these outputs will need to go through further steps to be fully ready for a production environment.

Evolving the Definition of Done

One final step exists in this journey towards a Definition of Done, one that, in my opinion, is perhaps the most valuable. That is to constantly re-evaluate what 'Done' means in the real-world context of a project – to apply principles of incremental improvement to the process as well as to the software that's being built.

By building multiple definitions of done into our methodology we have attempted to balance the value of getting features to users against the value of stability. But these values will shift over time. As a project matures, its stability will naturally increase, its landscape will settle, and this balance should be reviewed.

This iteration and evolution allow us to ensure that the Definition of Done is strict enough to ensure high-quality deployments, yet loose enough to allow efficient and truly agile development.  

Gethin Webster

Gethin Webster

Gethin is The AppWorks' Lead JavaScript Developer, with expertise in creating modern mobile applications for enterprise clients using technology such as React Native, Ember, and PhoneGap. He is also passionate about development methodologies and processes, and enjoys shaping our project lifecycle using concepts from Agile, Lean and SCRUM, alongside tools such as automated testing and continuous integration/deployment.

     

Leave a replay