Every user experience designer or software developer is familiar with questions like..
"How long will this feature take?"
"Surely, you've done this before. Can it be so hard?"
"Can you ship it by this Friday?"
Here's 4 ways to manage risk when estimating your user experience design or development work.
#Recommend a Spike
When there's confidence about the level of effort required to complete a task or project, estimating the work becomes a breeze.
This is where a spike comes in handy.
Spikes are time-boxed activities that determine the best path and steps for implementation.
The output of a spike is a technical plan and an estimate.
We like to recommend spikes to our Clients when a project is full of unknowns. This helps us ensure we're not over promising on the cost of implementation. And it also gives them a blueprint of the work that they can rely on.
Of course, spikes are not always possible given time constraints. In these cases, you can try estimating via story points..
#Estimate via Story Points
Story points map a feature estimate to a number (not in dollars), where the number represents the developer's level of certainty about how to implement the feature.
Traditionally -- and we like this approach here at With Pulp -- the numerical standard is the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, 34 etc.
The nice thing about the Fibonacci sequence is that the variance between every pair of numbers increases as you get further down the chain. This conveys ambiguity well as you can assign a larger number to a feature when there are more unknowns.
Story points are nice because they reduce pressure to get work done in fixed-hours constraints. And given the inherent complexity of software projects, they more accurately represent development work.
Over time, you can get a sense of how long something takes (on average) based on the story points assigned. However, this pattern will only emerge over several sprint cycles.
Until then, Clients might have a hard time making sense of story points. In this case, here's what you can do.
#Estimate via Ranges
If a Client persists on a time estimate, and you're unsure how long it would take, give them a ranged estimate instead (ie: 2-8 hours).
The bottom of the range is the best case scenario (ie: no bugs, no surprise cases) and the top range is the worst case where many assumptions were left out, unknowingly.
The larger the variange, the greater the level of uncertainty. This helps you communicate and manage risk.
Ranged estimates have their pitfall though because a Client will try and hold you to your ranges. You can reduce this risk by checking your ranges against similar features that you have delivered in the past.
But for even less risk, try this next approach.
#Ask for a fixed price
If you can, try to steer Clients away from hourly estimates altogether. They come riddled with risk for you and your Clients.
The fact is, as ux designers and software developers, we get more efficient at our crafts over time.
With each project, we learn more short-cuts. We get more reference examples. We acquire better tools.
This experience brings great value to our customers.
So at the end of the day, does it matter how many hours it takes?
Give your Client a fixed cost instead.
When you give a fixed price for your work, you manage risk for yourself and your Client. You know exactly what you will earn, and your Client knows exactly what they will invest.
--
Do you use any of these pricing strategies? Let us know in the comments below.
Until next time.