What is a relative measure (of estimation)? I found a good description of one of them in Derek Davidson’s article and adjusted it a bit for the use of this article:
“Relative unit of measure is a unit decided within a team to provide relative estimates of size of requirements and effort needed to fulfil them.”
Doesn’t explain much, does it? No worries – if you work on a product in an “agile” manner there is a high chance you use such techniques or have at least heard about them. When you ask yourself what’s a relative measure, think about key messages of stories, t-shirt sizes, and similar topics. They are relative, because they need to be compared against something. Each of them needs a certain point of reference that is sized using the same technique and is not described in time units. Why is that important? Because translating it to time units makes it as absolute as time itself, so the whole idea of being relative is gone. There is no point in such translation, because you can use only time units – adding another level of abstraction only increases unnecessary complexity.
The way relative measures are used is that when you need to estimate something (user stories, features, whole backlog, etc.), you discuss the item and the team votes about the size. Because you have the point of reference this is straightforward – if something is smaller, give one unit less than the reference. If bigger – one unit more. Much bigger – two units more. Units can vary a lot – I personally prefer Story Points (SP) using Fibonacci sequence – 1, 2, 3, 5, 8, 13 and so on. It shows that if we want to estimate really big things – the difference between a smaller unit and a bigger unit also grows, as unknowns also grow (dependencies, risks, etc.). In general – the smaller, the more accurate.