- Skipped Estimates: no-one wants really to skip them
- Quick & Dirty Estimates: management wants precision
- Fair Estimates: too crowded on Google because of “fare estimate”
- Guesstimates: terms like “guess” or “opinion” won’t work because very subjective
- Practical Projection: changing the term estimate would confuse the management in the lexicon
- Sensible Estimates: it could work, but still not buyable enough
- Practical Estimates: boom! They want estimates and gonna get it, plus they are practical which is a bonus because the process is fairly quick.
- No crazy formulas
- Rolling Wave Planning
- Effort estimation
- Complexity estimation
- Time estimation
What management really means is that estimates are promises — even forced estimates — and the team needs to keep their “promises,” even if they never promised.
With 90% of work done, the remaining 10% is refining the requirement, misread details, small UI-UX tweaks, blockers, code-review comments, build failure, etc. This 10% is highly underestimated and consumes significant time.
Individuals often consider the best possible outcome.
Dr Simon Moss
Company Maturity Assessment
|Colour||Description||Guiding Metaphor||Key Breakthroughs||Current Examples|
|RED||Constant exercise of power by the chief to keep foot soldiers in line.
Highly reactive, short-term focus. Thrives in chaotic environments.
|AMBER||Highly formal roles within a hierarchical pyramid.
Top-down command and control. Future is the repetition of the past.
|ORANGE||Goal is to beat the competition, achieve profit and growth.
Management by objectives (command and control over what, freedom over how)
|GREEN||Focus on culture and empowerment to boost employee motivation.
Stakeholders replace shareholders as the primary purpose.
|TEAL||Self-management replaces the hierarchical pyramid.
Organisations are seen as living entities oriented towards realising their potential.
- Not everyone is lucky enough to have the top management buy smoothly the uncertainty and the software lifecycle without many deadlines or de-scoping functionalities. See No Estimates.
- I’ve tried this method with a fairly small team of 7 people.
The 4 Key Processes
- Use the Eisenhower Matrix to group items together
- Focus only on Urgent-Important, Urgent-Not Important, Not Urgent-Important (in this order)
- Urgent-Important: We know we cannot do everything right now, so they’re gonna be planned
- Urgent-Not Important: It’s just urgent postponable stuff, but unfortunately is “urgent”
- Not Urgent-Important: Real schedulable work
- What about Not Urgent-Not Important: Let them stack up in the backlog, some day you’ll prune…
- Within a sector order by priority
- Use any relevant metric: urgency, complexity, date, profitability, and so on
- Get a prioritised tasklist following this order:
- Urgent-Not Important
- Not Urgent-Important
- Do Affinity Grouping based on the type of the activity: issues, task, enhancement, feature
- Do your estimation of a task based on the historical data of how long in average it took based on the activity type
- Each activity type has different timings, the time to fix an issue it is different from building a new feature. So treat them differently to achieve a better precision
- Review with the team if the estimates sound roughly good enough
- Use a Gantt Chart to help you visualise the workload
- Plan the work across different resources
- Plan at 70% capacity (think about sick days, holidays, meetings, …)
- Cut out whatever is not in the defined time span
- Review with the team the Gantt Chart
You could use a schedule like the following one:
- Monday – Thursday: work on urgent issues and scheduled work
- Friday: work on support issues and repaying technical debt.
- Each week check the progress
- Swap task assigned to resources whenever someone finishes all his/her workload
- Deliver each week part of the work, use a Feature Flag approach to make sure you can control the impact of the functionality.
Pro & Cons
- Quick estimates
- Saving the time of the team
- Enough precision
- Not enough precision
- Requires constant checkpoints
Rather than measuring using the classic velocity metric, it is way better to do the math based on the Running Tested Features. RTF has 3 main benefits:
- It is Running, hence it has been released in production, creating value for the end-users.
- It is Tested, meaning that it has been validated in different stages: unit testing, functional testing, integration testing and acceptance testing.
- It is a Feature, meaning that has real value for the end-users.
If you find you’re going to miss the planned deadline try to give as much notice as possible, in this way you can act accordingly and try to limit the damage. Also, make sure this kind of events are rare and you don’t miss too many deadlines, otherwise it’ll take a toll on the team’s morale.
Use burn-up charts for better visibility of changes of scope (which happens all the time).
A burnup chart clearly shows both completed work and project scope. The project will be completed when the lines meet.
The advantage of a burn up chart over a burn down chart is the inclusion of the scope line. It clearly tracks when work has been added to or removed from the project.
- The planning fallacy
- Underestimating Estimation
- Estimation is Evil
- What to Do When You Miss a Deadline at Work
- Moving Toward Teal Company’s Workflow
- Agile Antipattern: Everything is priority 1
- DAKI – DROP, ADD, KEEP, IMPROVE
- Web-Based Monte Carlo Simulation for Agile Estimation
- Why Do Managers Hate Agile?
- Aligning Workplace Learning to Organisational Paradigms
- What are Laloux’s “Evolutionary Breakthroughs in Human Collaboration”?
- 2. Evolutionary Context of Organisational Structures
- What is a burn up chart?
- Agile Metrics – Running Tested Features