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
Great blogpost! I will take this one along in my daily work. thanks!
ReplyDeleteerik
Nice stuff.
ReplyDeleteAn over-riding objective of testing is learning about the product. I like that you begin with the D; the deliverables are crucial—if you learn things that might be important to the client and you don't deliver them, your client could reasonably be upset. However, I'm not sure that the performance of testing—that is, the activity of learning—deserves to be in lower case.
You don't need a road map for exploratory testing, though you can certainly use any maps you already have. Indeed, one of the deliverables of testing is a new map (starting from the blank paper), or a refinement one that you already have by comparing it to the space that you're exploring That comparison is activity, which again to me is worth of an upper-case letter.
I liked someone (Liz Keogh's?) observation the other day that your product roadmap isn't a roadmap, but an itinerary—an idea of where you want to go, but without specific knowledge of where things are, or where they will be. Testing is one of the things that helps to create the map of what's there.
Cheers,
---Michael B.
Thanks Michael, while I do agree that the activities - ie. the actual work - is important, the reason I put the "a"'s in lower-case is that in a plan, I find that they do not in themselves explain to anyone what comes out of them. As you point out, in testing learning is a very very important activity, without which the value of the testing done may just evaporate.
DeleteStill, that is in the way I think of this heuristic "only" an activity that leads to a D. The D represents to me the knowledge that comes from the learning. The clearer we can get on what we would like to know, the more we can direct our testing towards learning just that - while learning a lot of other stuff, of course. The more unclear we are, as a project or in the plan, of this knowledge, the harder we have to work on obtaining it, which as I see it would require lots of revising plans and work. At least we get the gist of that this is the case from looking at the plan using this heuristic and figuring that the Goals and Deliverables aren't clear. :-)
Another reason to keep activities in lower-case is that I've seen so many PM's and others who just focus on those, forgetting the D's and loosing the overview. To me that's more than enough reason to keep them in lower-case - for the plan, that is.