So, what is DaRE=M ? It's a heuristic I use for testing a plan, like when someone tosses you a bunch of papers: "can't you drop an eye on this plan I made, just to see if I left anything obvious out?"
That's when I start on the "D" - which of course is for Deliverables. It's the first letter in the heuristic and also the most important one. I readily flunk plans that do not highlight the deliverables in a clear and consistent way. And why shouldn't I ? The plan is supposed to bring us somewhere so if we cannot read "where" from the plan, I don't have high regards for anything else in it.
The next letter is "a" - notice, it's not a capital A - it's minuscule and stands for activities. Surely there may be some activities in a plan, sometimes we just have to point them out - but: they are not as important as Deliverables and furthermore must always "hang on" to a deliverable (otherwise: why are we doing this activity ?). Clearly, if the activities are so overwhelming in the plan, that you cannot figure the deliverables, the plan is probably not going to work (it should be minuscule, not capitalized).
"Da" is a set - unseparable. Funnily if you open up a project planning tool, guess what's the first thing you are invited to put into it is ? Yup - an activity..
I think that's backwards - figure what you want, then plan your steps to get there!
The R and the E are of course Resources and Estimates, and yes, I put machinery and people under the same label here, although it seems to annoy some people. I consider it an honour to be "resourceful", but maybe my command of the english language isn't good enough to pick up the subtle insult in this. Never mind that now - for this purpose we need something to represent the limitations and constraints we experience in regard to who and what we can utilize for obtaining the Deliverables, and the estimated time/money/whatever we have to live by. I won't go to great lengths about estimation for now, as usually it's in fact pretty much a constant, not a variable, anyway. Again, the importance lies in whether any constraints in these matters have been considered, or not.
SO - we find ourselves at the "=".. it's there to make it look like a mathematical equation, although mathematical speaking it's rubbish. It's a heuristic only, folks, no time for accuracy as long as it lights up a synapse or two in your brain.
The idea is to invite you to balance the two sides of the equation - here the Deliverables, Resources and Estimates with the M, which represents the Milestones.
In other words: when someone asks: "when can this be done" they actually ask for the M's, and they are deductable from the set of DaRE.
If they asked a different question, like: "how many people do you need", you will have to rearrange the equation, isolating R: DaME = R.
And if they ask: "what can you do before [insert date]" - it will become REM=Da - or: it's a function of how many people and machines and rooms and stuff I got (since the E and M are practically given).
Yes, this resembles pretty much the famous project triangle of time, cost and deliverables, but I still think this elaboration is "mine".. well, now it's in the blog space, it's more like.. ours :-)
I remember it by pronouncing it "Dare'em", like in "Dare them to show me the plan", which in my curly brain makes sense, while native english speakers may wince..
As I started out with, I have been using this for a long time, and an addition came to it a few years ago: what if we have great unknowns ? This could be a testing plan, not a production plan, so we may not be able to put in the D's from the start, right ?
Not entirely right, as I see it. Over to the Dark Side you mustn't go, Luke - and you: - don't fall for the attempt to replace Deliverables with Activities; it will bring you only harm and suffering!
For exploration you still need a road map, although some or most of it is foggy and unclear. The absence of a goal is the major reason to object against exploratory testing, giving it labels like "hapsy-flapsy" and "unaccountable". What we do in this case is actually so simple most people would ignore it: we name our first steps as deliverables - still not the activity of taking a step, but if you imagine yourself with a pretty blank piece of paper as a roadmap in a very foggy world, what you do is look up and around and say something along the line of: "Let's travel to that stone over there and that rock down there. From those points we can look further into the shadows and figure what's on the other side. We're looking for a place to cross the river and a shelter for the night - let's go, guys!".
If you're lost in the wilderness this would probably make sense - and though we don't know too much about what we might find, we are still determining deliverables like "a place to cross river", and "a shelter".
The activities are "going to the stone" and "going to the rock" - the deliverable they belong to is: "further outlook".
Figuring that what we need is a shelter and a place to cross the river comes from your understanding of your situation - the "why you are here" question. You need some kind of overall goal to pursue, and the clearer the goal, the easier it is to create a plan. Often I've seen plans that are way too generic, almost text book-ish, and leaves me with only questions about what the entire purpose of the plan might be. So an appropriate addition to the heuristic would be adding a Go for "Goal", so it becomes
Go DaRE=M
