It is more important for a plan to be realistic and ultimately for it to be achieved than for you to be heroic. If you make unrealistic plans, you may feel better today when you’re offering the world, but the company and your career will suffer when you fail to deliver. If you make under-achieving plans, the company may not be able to afford/justify your continued employment.
Points vs. Hours
Source: http://en.wikipedia.org/wiki/Brooks’_lawBrooks’ Law: adding manpower to a late software project makes it later
In software engineering, the man-month (or person-day) is mythical. Time required is relative to environmental context, organizational maturity, available information, and is confounded by collaboration overhead. Measuring projects in terms of “hours” or “days” ignores these confounding factors and creates a false sense that time is an absolute commodity.
Programmers are very good at estimating relative size (points) of a task but terrible at estimating absolute time required to complete the task. Real world adaptive measurement is excellent at measuring time required to complete tasks and can be combined with relative estimations to achieve realistic plans.
Burndown Chart
Source: http://en.wikipedia.org/wiki/Optimism_biasOptimism bias is the demonstrated systematic tendency for people to be over-optimistic about the outcome of planned actions. This includes over-estimating the likelihood of positive events and under-estimating the likelihood of negative events.
Every day at the Scrum stand-up meeting you must be prepared to accurately report the points remaining on all extant tasks. This vital data provides feedback regarding velocity and gives early warning of schedule slippage. The burndown chart is the number one most valuable asset management has for accurately understanding the status of the project. Without this tool, management is likely to lose trust in the team and may make less rational decisions about risk management due to lack of available accurate data. Even a burndown chart that shows extreme schedule slippage is better than no burndown chart at all.
Timeboxing
Source: http://en.wikipedia.org/wiki/Parkinson’s_lawParkinson’s Law: Work expands so as to fill the time available for its completion.
Once you have committed to the size of a task, and you know your current velocity, you should create a timebox for that task. Know when the task must be completed by and ensure you can complete it within that window. Cut features and look for ways to reduce the scope if necessary. Seek input from the Scrum Master and Product Owner as soon as possible if you are going to break your time box. If you miss your timebox now, where will you make up the time?
Slack
Source: http://en.wikipedia.org/wiki/Hofstadter’s_lawHofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Time slippage is always cumulative. You can always lose time through poor planning or unexpected problems, but you will never get time back unless you plan for it. All long range schedules must include un-planned slack time. This time can soak up schedule slippage in the worst case, and will be used to improve process or reduce technical debt in the best case.
Distraction vs. Subconscious Processing
We’ve all had that brilliant moment of inspiration in the shower or on the walk to the office. We’ve all felt completely stymied while we sit and stare at our text editor at our desks. Stress significantly reduces creative flow. It is perfectly natural for an information worker to need to step away from the code and let the unconscious mind chew on a problem in order to maximize efficiency. Mindfully knowing when to go for a walk around the block, stretch the muscles, shift temporarily to a lower priority task, or have a brainstorming session with a peer is a great skill to nurture.
The Web has great resources for getting your problems solved. Sometimes a Google searching session, review of relevant blogs, chat with friendly experts, watching an inspirational TED video, or a Wikipedia walk will reveal an existing solution to your problem or inspire a new variation on an old approach.
However, there are a number of activities which are pure distraction. Checking your personal email, watching an unrelated YouTube video, planning an event on Face book, or browsing the latest gadgets on a techblog are not reasonable means to maximize subconscious processing. These are not acceptable practices during your work day. These activities so actively occupy the mind that the unconscious is unable to process the problems you’re facing. These are simply procrastination.
You are encouraged to take the occasional walk around the block, or trip to the local park/cafe with a notebook, stretching break at your desk, or brainstorming session with a peer. You’re welcome to spend a reasonable amount of time searching internet resources for a solution to your technical problems. These activities must contribute to on-time delivery of your commitments.
If you are delivering on time, your time usage will not be micro-managed. It is in your interest and the interests of the team that you be self-accountable for your time. When you choose to do something other than directly performing your task, what is your reason? Will the thing you’re doing help or are you just procrastinating? If you fail to meet your commitments, procrastination activities will not be tolerated.
