Friday, March 28, 2008

Gist: to improve on estimating how long a given task will take. To give a well grounded answer to the question: "When will this be finished?"Note: although this process aims at personal velocity, it can be adapted towards team velocity. But mind entry condition E1, every team member will have to fulfill it.

velocity DEFINED AS the number of task-points done per day.

Entry Conditions:E1: You must be willing to take notes of all your tasks and review them regularily, i. e. once a week.

Process:S1: for every task you get or generate for yourself, do a rough estimate on its complexity. Simply give points ('gummi bears'), use Fibonacci's numbers for that, i. e. 1, 2, 3, 5, 8, 13, 21, 34, ... (each number is the sum of the two preceeding ones). "If task A was worth 5 points, Task B is a bit more complex, so I will give an 8."Note: It is not important to estimate for example the hours you'll probably need. A relative meter is sufficient.Note: For me, this takes 5 seconds longer than just jotting down a task. With about 30 tasks/week this adds up to whopping 2,5 minutes this substracts from my weekly work time.

S2: whenever you finish the task, just mark it 'done'. No need to recalculate your original estimate.Note: This works because of a levelling effect over time and the number of tasks. See Notes below.

S3: Regularily (I go for once a week), sum the points of all tasks you finished since last time (e. g. the past 7 days). Do it at least a couple of weeks to get credible results.Note: I do it all the time because I found that my velocity changes with the projects I work on. It takes 3 minutes per week.

S4: Divide the sum by the number of days you actually worked on tasks, so that holidays, etc. are not factored in. The result is your velocity, Gummi Bears Done per Day.Note: you can decide to factor in holidays and the like, but then you will need a much more data in order to come up with useful answers.

S5: Whenever you are asked the magic question "When will this be finished?", do the rough estimate of S1 on 'this'. Divide it by your velocity. The result is the time you will need, in days. Don't forget to think about when you will start to do the task before answering...Note: I use the average velocity of the last 5 weeks, to take changing velocities into account. Maybe after a year I find that it is good enough to use the year's average velocity.

Notes:The steady estimation process S1 will level out a couple of unwanted effects:- you will have good days and bad days- you will have to estimate rather small AND rather large tasks- one day, you will finish that monster task you estimated with 55 gummi bears, and this will boost this weeks sum.- your always optimistic (or pessimistic) with your estimates- tasks sometimes will have subtasks, that both appear in your task list side-by-side. 'this is not a problem unless you do a complete work breakdown

To give you a hint, tasks in my list range from 'Call Andy' to 'Write a new requirements management plan for Project A'.

I misuse MS Outlook's® Task-Details for keep track of the estimates. I don't care if the field says ' x hours', for me it's just 'x'

feature FOR THIS POST DEFINED AS a thing to be implemented, could well be a requirement, a user story, a use case. Whatever your backlog consists of.

Entry-Conditions:E1: Each feature in your backlog needs to have an estimate, best measured in some points, gummy-bears etc. (Make the sum of all features your parameter TSPP, total sum of planned feature points)Note: It's not imortant that these estimates represent actual budget, time or similar. They have to be consistent with each other and represent properly the relative relations between themNote: You can adjust the number later but you will have to recalculate things (see S3-S5).E2: You need to know how many iterations you will undertake. (Make this your parameter TNI, total number of iterations).Note: Ideally, iterations are all the same length, i.e. timeboxes. You can adjust the number later but you will have to recalculate things (see S3-S5).E3: You need to know the budget you are about to spend, from now to the end of the last iteration (make this your parameter TBP, total budget planned).E4: You need an established way of tracking how much budget you have actually spent on each of the iterations.Note: This can be obtained by maintaining a log of workhours spent on the project by each of its members.

Process:S1: After every iteration, find out how much budget you have actually used for the iteration. Sum it up over all finished iterations. Make this your ABS, actual budget spentS2: After every iteration, find out how many points you have actually implemented within all iterations (= ASI, actual sum implemented). All the feature's points count as implemented if and only if the feature is in full effect.Note: this means you have to have a clear understanding what 'done' means for a feature.

Problem DEFINED AS difference between things as desired and things as conceivedNote: Don's and Gerald's original definition stated 'perceived' instead of my 'conveived'. I changed this due to some buddhism-oriented mindset of mine. Thanks to my friend Sven for reminding me.

PrinciplesP1) Each solution is the source of the next problem.P2) Moral issues tend to melt in the heat of a juicy problem.P3a) You can never be sure you have a correct problem definition, even after the problem is solved.P3b) You can never be sure you have a correct problem definition, but don't ever stop trying to get one.P4) The trickiest part of certain problems is just recognizing their existance.P5) There are problem solvers and solution problemers.P6) In spite of appearances, people seldom know what they want until you give them what they ask for.P7) The fish is always last to see the water.P8) In the valley of the problem solvers, the problem creator is king.

ProcessS1) Ask: Who has the problem? Then, for each party, ask: What is the essence of your problem?S2) think of at least three things that might be wrong with your understanding of the Problem. If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem.S3) Test your problem definition on a foreigner, someone blind, or a child, or make yourself foreign, blind, or childlike.S4) Generate points of view. Every point of view will produce new misfits between problem and solution.S5) As you wander the weary path of problem definition, check back home once in a while to see if you haven't lost your way.S6) Once you have a problem statement in words, play with the words until the statement is in everyone's head.S7) Ask: Where does the problem come from? Who sent this problem? What is she trying to do to me? The source of the problem is most often within you.S8) Ask yourself: Do I really want a solution?S9) Ask Why 5 times. Normally this leads you to the essence of the problem.S10) If a person is in a position to do something about a problem, but doesn't have the problem, then do something so he does.S12) Try blaming yourself for a change - even for a moment.

RulesR1) Don't take s.o. solution method for a problem definition - especially if it's your solution method.R2) Don't solve other people's problems when they can solve them perfectly well themselves. If it's their problem, make it their problem.R3) If people really have their lights on, a little reminder may be more effective than your complicated solution.R4) If you solve s.o.'s problem too readily, he'll never believe you've solved his real problem.R5) Don't leap to conclusions, but don't ignore your first impression.R6) We never have enough time to do it right, but we always have enough time to do it over.R7) We never have enough time to consider whether we want it, but we always have enough time to regret it.