Escape the Groundhog Day of Testing (part 5)

Deflecting stupid change requests

This diagram is all you need. Print it out. Put it on the wall. Anyone comes near your desk?

Without lifting your eyes from your screen, point at this diagram and say “If your problem fits into that sentence without me laughing, we’ll consider the work request you’re about to make”

Forcing everyone to go through some thinking about their ‘thing they want’ is a great way to deflect stuff that’s truly weak and unsupported.

Print out a copy for anyone, particularly the really annoying person (you know who I mean) who’s always asking the team to deliver spectacularly ego riddled, opinion led or naked assumptions into the product.

There’s also this slightly tweaked version, thanks to Doug Hall and Lukas Vermeer. I’ve extended mine to include their thinking around expectations of test cycles. I may create a revised version but let me know what you think of both of these.

[H] Here is your expectation of the lift that the test will generate (essentially the change in the KPI you’ve set out to measure for the test success). This is very important in test design because the size of the expected effect influences the time you need to run the test. It’s hard to see small changes against the background data noise of a website so the expected lift influences the likely time for testing.

[I] is also important — as you may need to test for at least 1 (I normally run 2) minimum business cycles. If you’re an ecommerce company, the small unit of your cycle is a weekly one (most likely). If you are a payday loan company, your cycle is going to be monthly.

In the final part of this series, I’ll talk about the Cultural Impact of decently formed hypotheses.

“I seriously believed that my last hour was approaching, and yet, so strange is imagination, all I thought of was some childish hypothesis or other. In such circumstances, you do not choose your own thoughts. They overcome you.”

Jules Verne