Why do you need to read this?
In order to develop software in (at least seemingly) effective and professional manner, it is useful to have a set of guidelines for what is considered "ready for development".
Should you bother with this?
If you at all care about what should and shouldn't be a part of task definition, you might benefit from this post. I have created it with developers in mind, but I see no reason others might not find something useful here.
Defining Ready
To consider a task "Ready" I usually require a task to be these 3 things:
- Valuable (as in, having value for someone)
- Estimable (to a decent approximation)
- Testable (if not now, then in future)
Every single of these points exists for the sake of clarity - clarity of what needs to be developed and clarity of what will be delivered. It is a team effort to have all these well defined, not something that falls onto one single person.
So how do we check for these three properties? We ask ourselves the following questions:
Is it Valuable?
If a task does not bring new value to the project or does not resolve an outstanding issue, why would you spend time working on it? This holds for both new features and bug fixing - removing a bug inherently brings value to the project. Very few tasks will have explicit statement about the value that it brings - that is why you need to understand what is it you need to make. If you do not see it, raise that issue and discuss it. Understanding how this feature benefits the project is a crucial part of prioritizing and implementation.
Is it Estimable?
You need to be able to estimate the effort required to finish the task. If you can not give an effort estimate, chances are you do not understand the task enough and additional clarifications are required. It is not often that I see the task so simple that i can estimate it without any assumptions. The idea here is that you keep a mental (or written) list of assumptions made while estimating a task - if any of the assumptions can influence the implementation by more than a few hours, it pays off to discuss it and remove any uncertainty. When you can estimate the effort, that means that you understand what needs to be done and also, importantly, you can manage expectations regarding delivery times or deployment.
Is it Testable?
Can you really say that you have finished working on a task without having a way of proving that it, as a matter of fact, is finished? For this purpose, we require a reliable way of testing the result of our work. Some things are easy to test - changed label requires only a glance, while some other features may require elaborate preparation and detailed instructions. If you were fixing a bug, you must be able to demonstrate that it can no longer be reproduced. Sometimes, testing a feature will require a separate feature to be implemented first - one that also needs to pass the VET rules.
To VET or not to VET
Surely, you can take up a task, work on it and finish it without all these rules, and good for you! But if you don't know why, when, or how - can you really feel like you know what you are doing? There are numerous approaches to knowing if a task is ready, and this one is one that I use and has served me well over the years.
Do you feel differently? Let me know in the comments, I would really love to hear what you have to say.