Menu
Planning with relative estimation can leave stakeholders in a discomfort zone, due to the uncertainty. That’s ok though. Creating something new rarely means using copy-and-paste components from prior work, so there will be uncertainty when navigating to the solution.
The relative estimation technique requires everyone involved to apply agile thinking such as “inspect and adapt”; mainly because the work is new and isn’t easily compared to other work. Inspect and adapt, that is another way of saying figure it out by doing. At a high level, you create a hypothesis, work and test it, then evaluate it. This is risky and can be expensive – no surprise there. But, what if “this is what we’re doing now,” and you need to appeal to the new standards?
Relative estimation in a nutshell:
I once heard a mentor discussing techniques with another practitioner. They said take the high level, take the low level, and then average – boom there’s your rough [relative] estimate of effort.
This should be a familiar concept. We typically use similar methods to regularly estimate work. Our normal method uses traceable data and realistic units to average, calculate, or estimate work efforts. Remove the data and realistic units (i.e. dollars, hours, etc.) and you’ll have to subjectively estimate solving a problem based on relative effort.
To begin, the team discusses effort by asking questions. Then, collaboratively decides together what relative efforts mean to them, based on their expertise. In the agile mix, people use a guide such as “in an ideal day, this will take X effort to complete,” or something similar.
Managing this process means accepting the same way of thinking as the team and adhering to the protocol, by tracking measurable value vs. units that translate to dollars. Hint: this is why we start with step 1.
Let’s apply relative estimation in real-life example.
Suppose I order something online would it be acceptable for the company to tell me I’ll receive my order in 5 story points? What does that mean to me as the customer? I like knowing when I’ll get my order before I buy, so that would be a hard no! However, that same company could use relative estimation for an increment of the process vs. the total process cycle to innovate fulfillment at the warehouse. A story point estimation would make more sense for the bulk mechanics of “the person pulling the order communicates the progress data to the system so that the customer can have a live update of their order status.”
Why?
Two reasons: I won’t stop my online behavior while the company reworks their process, and there are other companies I can shop with if this company cannot construct a process that meets my needs.
Accuracy using relative efforts to estimate work is tricky. Estimating in relative terms requires practice. Honing, adapting the defined values of previous iterations to what most can agree feels like a story point for the future iterations. Go and have some fun analyzing and improving your estimation process!