During a recent project where we were adopting aspects of Agile into a very waterfall environment I found myself repeatedly verbalising the concept of ‘definition of done’ to project owners and sponsors. This explanation was met with satisfied faces from people who loved the concept. This lead me to think how this seemed to be a revolutionary concept where it is something that I live by and strive to do everyday.
The essence of what it means is that for every task there is a set of criteria that enable us to mark a deliverable or task as done. Often completing all these tasks on its own does not classify this deliverable or task as done. Creating a definition of done would be the action or task that enables us to classify this as done.
An example is in a project where we need to add a complaint capture screen to a website. A business analyst might work on the requirements and pass this on to a developer that develops the functionality. Is the fact that the functionality has been developed sufficient to consider this requirement as delivered? To answer that let’s look in detail at the requirement and what we are trying to achieve is the form of a user story broken into three parts.
[As a customer] [I want to submit an online complaint] [in order for my issue can be actioned]
In the above example we can extract that the requirement is the functionality that enables the client to submit a complaint online. When a developer builds this functionality it is often done on a QA environment which the client has no access to. So how can the requirement be met if the client is not able to complain through the online channel? Theoretically the only time we can say we have successfully met this requirement is when a client has the functionality available to them to complain on the online system and the data is passed through to the organisation to action.
As we know in a project many steps need to be taken in order to get to the client being able to submit his/her complaint. This could include analysis, development, testing, approvals, sign off’s, deployments and any other project related steps. These are all steps to the end deliverable but not the deliverable itself. This leads me to a statement which might come as a shock to a Business Analyst.
A business analyst does not actually deliver anything. Many will ask how I can say that, especially being a business analyst myself. Well let’s look back at another core principle of Agile development. Working software over comprehensive documentation. In the above example it is very clear that the BA writing a document does not mean that the client can complain through the online channel. We can’t go to the client and tell them we have a document that explains how you will be able to complain, this will not meet their expectation. Under the same train of thought can we tell the client that we are 95% complete with the online complaints capture?
To conceptualise this put yourself in a customer’s shoes. Let’s say you go to a dealership and order a car. You are told to come back in 10 days and pick up the car, on the 10th day you arrive only to be told that your car is not ready as the order didn’t reach the factory in time to process. Does it matter to you that the car salesman completed all the right documents and submitted them to the administrator who was on lunch at the time, and was only able to submit the documentation at a later stage? No, you don’t care, the only thing you understand is that you are catching a taxi home.
So how can we improve this? Understanding a definition of done and stating it upfront is critical. In my mind there are only two levels of completion, 0% and 100%. There is no in between, 50% delivered does not mean anything to anyone. This could however conflict with project management methodologies. So how do we make it work at a lower more incremental level. In the same way that a requirement has a definition of done so can sub items within the requirement. In the analysis phase for example a definition of done can be that the requirement is signed off by the project sponsor/owner. A BA can produce a great document, use case or user story with the requirement perfectly defined but unless it has been signed off and agreed to it means nothing to the project.
Often the definition of done is linked to an external constraint and it is frustrating thinking that the work that I have done could be unusable until someone has approved it but that’s just the way it is. Yes, it is frustrating that I have done all this work and it is sitting on a desk before it can be delivered. Yes, it holds the process up but until it is signed off it can’t be delivered and the functionality can’t be built. But without that one signature you can’t say that the step in the project is done. How many times have you heard someone blame an external party for their deliverable? “I missed the deadline because I am waiting for an email”.
If you take a step back and look at the bigger picture and the role the BA has to play in it you start to understand why definition of done is so critical to the project. This realisation can be the difference between a good BA and a great BA. Understanding that the BA can be part of the strategic direction of the business rather than just there to create a requirement document is where every BA should strive to be. Taking ownership of the definition of done of your allocated tasks ensures that you will be able to add real business value. Taking ownership means understanding what the definition is before starting work on it.
In summation I think that even if you are not in a fully agile environment you are able to take agile principles and apply them. These principles will make the BA better at what they do and more of an asset to a business. Take ownership of the task you have to perform, remember that there is a difference between accountability and responsibility. Finally always seek to fully understand the definition of done for any task you are assigned as this will make sure that your stakeholders are kept happy and you deliver according to what they deem complete.
Author: Ryan Folster, Business Analyst
Ryan Folster is an up-and coming Business Analyst from Johannesburg South Africa. His strong focus on innovation as well as involvement in the Business Analyst community have seen Ryan develop professionally from a small company, serving a small amount of users, to large multi-national organisations. Having merged into Business Analysis through the business domain, Ryan has developed a firm grounding and provides context to the methodologies applied to clients and projects he is working on.
Ryan has gained exposure to the Human Resources, Asset Management as well as Financial Services sectors, working on projects that span from Enterprise Line of Business Software to Business Intelligence and Compliance. Ryan is also heavily involved in the local chapter of IIBA, currently holding the position of Head of Technology and Social Media.
Ryan is passionate about the role a Business Analyst plays within an organisation, and is a firm believer that the role will develop further in the future and become a crucial aspect of any successful business.
To get into contact please use one of the below channels
Email: [email protected]
LinkedIn: za.linkedin.com/pub/ryan-folster/12/128/639
Twitter: @ryanfolstersa