From what I learned 'estimate' has quite a different notion in my book than in his. Considering the fact that with me 'in my book' is only a manner of speaking while David actually 'wrote the book' (on Kanban in software development that is) I thought it would be a good idea to question our differences a little more thoroughly.
The initial difference is the statement, that in Kanban there are no estimates (missing source, perhaps misquoted) while on the other hand (as Olaf Lewitz noted [see below]) in the definition of service classes (on pg. 131 to be exact) David states "No estimation is performed..." but "Standard class items may be analyzed for size. Large items may be broken down into smaller items.".
Two things are notable here for me - the first one is, that I filtered out the second half of the first sentence. What he really says is "No estimation is performed to determine a level of effort or flow time."
The second one is my reaction to the idea of "No estimation but analysis".
For me it is very important to tell people, that you don't have to know the exact size/effort/duration of a task but that it's OK to estimate. So the point for me is 'to estimate' is important to get over the negotiation phase and to avoid getting stuck in analysis paralysis. From what I read from one of Davids tweets I gather that for him it's important that the analysis of a class item should not contain any assumptions about how long it will take and when the item could/should be delivered. (On the other hand I could off course also have a complete misunderstanding of his intentions...)
So now it seems:
'to estimate' => good from my point of view because it frees from BDUF risk
'an estimate' => not so good from Davids point of view because it implies known effort and delivery date
But on a related note David wrote:
"so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation"
As much as I can relate to that point of view I still have a great problem with the wording because ever so often when some (not all) developers hear/read that they don't have to estimate any longer if method/process
So, even when applying Kanban I would still like my teams to have the freedom to give estimates on item sizes - especially on big ones. And even on small item I would alway want a way to include a "give or take" to any number that's being passed around. And for me this leeway is what differentiates an analysis based on exact calculations from a plan that is based on estimations.
So David, should you read this (as I hope you will) - is our difference just a question of wording (English is still a foreign language to me) or is there really a fundamental difference in our position?
Just for the record: the original Twitter threads:
Thread 1:
(ended at msg. id:16427657813)
agilemanager says:
@MMahlberg "'too large' is an estimate" only in the most degenerate of senses. It is not something you can plan or commit from
MMahlberg says:
@agilemanager analysis!=estimation: ok, estimation!=decomposition: ok, but decomposition involves estimation (e.g. 'too large' is estimate)
agilemanager says:
@MMahlberg for me estimation involves a time and a delivery date. it's not decomposition. analysis is not estimation
MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?
agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is
OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?
Thread 2:
(ended at msg. id: 16426940354)
agilemanager says:
@MMahlberg so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation. is this clearer?
MMahlberg says:
@agilemanager agreed: UML != estimation (notation/language vs. activity)
agilemanager says:
@MMahlberg for example you would never describe UML as an estimation technique
MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?
agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is
OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?
