It all started while working as CTO (first-time though) at Skuola.net<\/a> and attending the conference Codemotion Rome 2019, I was listening to Daiany Palacios<\/a> talking about hers \u201c The trap of averages. How to avoid it in software development estimates<\/a>\u201d in particular about doing estimates using the Montecarlo method<\/a>. That moment something triggered in me, like an epiphany\u2026 I had put a lot of effort into my process improvements, but that was another spark to keep raising the bar again.<\/div>\n

Then during a job interview, some time later, I\u2019ve got asked about my method, and they were interested in my approach.<\/div>\n

This episode, a few days later, got me thinking that maybe I could share it to the world \ud83d\ude09<\/div>\n

Since it kinda worked for me most of the times (let’s say 80% of the times), I could have formalised it and tried to fix the weak spots. So here it is.<\/div>\n

This method is only valid at some stage of company maturity, early ones could benefit from it, mature one could avoid it entirely. It depends on the company’s needs.<\/div>\n

<\/p>\n

How did I come up with Practical Estimates? It was mainly to let the concept be transparent with the name and to make the adoption easier. Difficult names will make harder for the management to buy the concept, here are some failed attempts:<\/div>\n

Skipped Estimates<\/em>: no-one wants really to skip them<\/li>\n

Quick & Dirty Estimates<\/em>: management wants precision<\/li>\n

Fair Estimates<\/em>: too crowded on Google because of “fare estimate”<\/li>\n

Guesstimates<\/em>: terms like “guess” or “opinion” won’t work because very subjective<\/li>\n

Practical Projection<\/em>: changing the term estimate would confuse the management in the lexicon<\/li>\n

Sensible Estimates<\/em>: it could work, but still not buyable enough<\/li>\n

Practical Estimates<\/strong>: boom! They want estimates and gonna get it, plus they are practical which is a bonus because the process is fairly quick.<\/li>\n<\/ul>\nConcepts<\/h2>\n
\n
No crazy formulas<\/li>\n
Rolling Wave Planning<\/a><\/li>\n
Effort estimation<\/li>\n
Complexity estimation<\/li>\n
Time estimation<\/li>\n<\/ul>\n
Why?!<\/h2>\n
Because…<\/span><\/p>\n
What management really means is that estimates are promises \u2014 even forced estimates \u2014 and the team needs to keep their \u201cpromises,\u201d even if they never promised.
\n Ron Jeffries<\/a><\/p><\/blockquote>\n
$\"Estimate$ <\/a>
Estimate Of Timeline – Dilbert by Scott Adams<\/figcaption><\/figure>\n
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.
\n Ranganathan Balashanmugam<\/a><\/p><\/blockquote>\n
$\"Dilbert$ <\/a>
Dilbert by Scott Adams<\/figcaption><\/figure>\n
Individuals often consider the best possible outcome.
\n Dr Simon Moss<\/a><\/p><\/blockquote>\n
$\"Different$ <\/a>
Different Time Estimates – Dilbert by Scott Adams<\/figcaption><\/figure>\n
Company Maturity Assessment<\/h2>\n
This concept is based on Frederic Laloux\u2019s definition in his book \u201c Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness<\/a>“<\/div>\n\n\n\n\n\n\n\n\n
Colour<\/strong><\/td>\n Description<\/strong><\/td>\n Guiding Metaphor<\/strong><\/td>\n Key Breakthroughs<\/strong><\/td>\n Current Examples<\/strong><\/td>\n<\/tr>\n
RED<\/span><\/td>\n Constant exercise of power by the chief to keep foot soldiers in line.<\/p>\n
Highly reactive, short-term focus. Thrives in chaotic environments.<\/td>\n
Wolf pack<\/td>\n \n
\n
Division of labour<\/li>\n
Command authority<\/li>\n<\/ul>\n<\/td>\n
\n
\n
Organised crime<\/li>\n
Street gangs<\/li>\n
Tribal militias<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
AMBER<\/span><\/td>\n Highly formal roles within a hierarchical pyramid.<\/p>\n
Top-down command and control. Future is the repetition of the past.<\/td>\n
Army<\/td>\n \n
\n
Formal roles (stable and scalable hierarchies)<\/li>\n
Stable, replicable processes (long-term perspectives)<\/li>\n<\/ul>\n<\/td>\n
\n
\n
Catholic Church<\/li>\n
Military<\/li>\n
Most government organisations (public school systems, police departments)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
ORANGE<\/span><\/td>\n Goal is to beat the competition, achieve profit and growth.<\/p>\n
Management by objectives (command and control over what, freedom over how)<\/td>\n
Machine<\/td>\n \n
\n
Innovation<\/li>\n
Accountability<\/li>\n
Meritocracy<\/li>\n<\/ul>\n<\/td>\n
\n
\n
Multinational companies<\/li>\n
Investment banks<\/li>\n
Charter schools<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
GREEN<\/span><\/td>\n Focus on culture and empowerment to boost employee motivation.<\/p>\n
Stakeholders replace shareholders as the primary purpose.<\/td>\n
Family<\/td>\n \n
\n
Empowerment<\/li>\n
Equalitarian management<\/li>\n
Stakeholder model<\/li>\n<\/ul>\n<\/td>\n
\n
\n
Businesses that are known for idealistic practices (Ben & Jerry\u2019s, Southwest Airlines, Starbucks, Zappos)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
TEAL<\/span><\/td>\n Self-management replaces the hierarchical pyramid.<\/p>\n
Organisations are seen as living entities oriented towards realising their potential.<\/td>\n
Living organism<\/td>\n \n
\n
Self-management<\/li>\n
Wholeness<\/li>\n
Evolutionary purpose<\/li>\n<\/ul>\n<\/td>\n
\n
\n
A few pioneering organisations (Patagonia, Buurtzorg, FAVI, Morning Star, ESBZ)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Source: Frederic Laloux, Reinventing Organizations [Nelson Parker, 2014]<\/div>\n
<\/div>\n
Check your organisation with the following assessment:\u00a0https:\/\/www.beyondteal.com\/teal-organizational-readiness-assessment<\/a><\/div>\n
<\/div>\n
\u2139\ufe0f Info: <\/strong>This estimation method is mostly applicable in red\/amber\/orange organisations.<\/div>\nNotes<\/h2>\n
\n
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<\/a>.<\/li>\n
I’ve tried this method with a fairly small team of 7 people.<\/li>\n<\/ul>\n
The 4 Key Processes<\/h2>\n
Sorting Process<\/h3>\n
\n
Use the Eisenhower Matrix<\/a> to group items together<\/li>\n
Focus only on Urgent-Important, Urgent-Not Important,\u00a0Not Urgent-Important (in this order)\n
\n
Urgent-Important: We know we cannot do everything right now, so they\u2019re gonna be planned<\/li>\n
Urgent-Not Important: It\u2019s just urgent postponable stuff, but unfortunately is “urgent”<\/li>\n
Not Urgent-Important: Real schedulable\u00a0work<\/li>\n
What about Not Urgent-Not Important: Let them stack up in the backlog, some day you\u2019ll prune…<\/li>\n<\/ul>\n<\/li>\n
Within a sector order by priority\n
\n
Use any relevant metric: urgency, complexity, date, profitability, and so on<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Estimation Process<\/h3>\n
\n
Get a prioritised tasklist following this order:\n
\n
Urgent-Important<\/li>\n
Urgent-Not Important<\/li>\n
Not Urgent-Important<\/li>\n<\/ol>\n<\/li>\n
Do Affinity Grouping<\/a> based on the type of the activity: issues, task, enhancement, feature<\/li>\n
Do your estimation of a task based on the historical data of how long in average it took based on the activity type\n
\n
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<\/li>\n<\/ol>\n<\/li>\n
Review with the team if the estimates sound roughly good enough<\/li>\n<\/ol>\n
\u2139\ufe0f Info:<\/strong> Do have a look at No Estimates<\/a> since the concept is great, you’ll find more interesting topics that will help you.<\/div>\n
\u2139\ufe0f Info:<\/strong> We are bad at estimating and each one takes into account his perspective. To be objective we need to be backed by data, even if it’s not precise.<\/div>\n\n
\u2139\ufe0f Info:<\/strong> Try to gather as much data as possible about the historical lead time or worked time from project tracking tools by querying directly their internal database. For example, if you use self-hosted GitLab or Jira you can access their PostgreSQL database and harvest data.<\/div>\n<\/div>\n
\u26a0\ufe0f Pay Attention:<\/strong> There should be no link between abstract units<\/a> (Fibonacci series, t-shirt sizes, and so on) and time. Remember that the management cares about time, it’s how human measure things. They will find a way to hack any framework to map it to working days.<\/div>\n
\u26a0\ufe0f Pay Attention: <\/strong>Each team must have its own estimation (they cannot be mixed up) and they should be added together to obtain the final figure.<\/div>\nPlanning Process<\/h3>\n
\n
Use a Gantt Chart<\/a> to help you visualise the workload<\/li>\n
Plan the work across different resources\n
\n
Plan at 70% capacity<\/a> (think about sick days, holidays, meetings, \u2026)<\/li>\n<\/ol>\n<\/li>\n
Cut out whatever is not in the defined time span<\/li>\n
Review with the team the Gantt Chart<\/li>\n<\/ol>\n
You could use a schedule like the following one:<\/p>\n
\n
Monday – Thursday: work on urgent issues and scheduled work<\/li>\n
Friday: work on support issues and repaying technical debt.<\/li>\n<\/ul>\n
Execution Process<\/h3>\n
\n
Each week check the progress<\/li>\n
Swap task assigned to resources whenever someone finishes all his\/her workload<\/li>\n
Deliver each week part of the work, use a Feature Flag<\/a> approach to make sure you can control the impact of the functionality.<\/li>\n<\/ol>\n
\u2139\ufe0f Remember: <\/strong>Agile is about fixed time and cost and flexible scope. For more details check the Quality Triangle<\/a>.<\/div>\n
Pro & Cons<\/h2>\n
Pro:<\/div>\n
\n
Quick estimates<\/li>\n
Saving the time of the team<\/li>\n
Enough precision<\/li>\n<\/ul>\n
Cons:<\/div>\n
\n
Not enough precision<\/li>\n
Requires constant checkpoints<\/li>\n<\/ul>\n
Measuring<\/h2>\n
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:<\/p>\n
\n
It is Running, hence it has been released in production, creating value for the end-users.<\/li>\n
It is Tested, meaning that it has been validated in different stages: unit testing, functional testing, integration testing and acceptance testing.<\/li>\n
It is a Feature, meaning that has real value for the end-users.<\/li>\n<\/ul>\n
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.<\/p>\n
Tools<\/h2>\n
Use burn-up charts for better visibility of changes of scope (which happens all the time).<\/p>\n
$\"burn$ <\/a><\/p>\n
A burnup chart clearly shows both completed work and project scope. The project will be completed when the lines meet.<\/p><\/blockquote>\n
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.<\/p><\/blockquote>\n
References<\/h2>\n
\n
The planning fallacy<\/a><\/li>\n
ThrownEstimate<\/a><\/li>\n
Underestimating Estimation<\/a><\/li>\n
PurposeOfEstimation<\/a><\/li>\n
Estimation is Evil<\/a><\/li>\n
What to Do When You Miss a Deadline at Work<\/a><\/li>\n
Moving Toward Teal Company\u2019s Workflow<\/a><\/li>\n
Agile Antipattern: Everything is priority 1<\/a><\/li>\n
DAKI \u2013 DROP, ADD, KEEP, IMPROVE<\/a><\/li>\n
Web-Based Monte Carlo Simulation for Agile Estimation<\/a><\/li>\n
Why Do Managers Hate Agile?<\/a><\/li>\n
Aligning Workplace Learning to Organisational Paradigms<\/a><\/li>\n
What are Laloux’s “Evolutionary Breakthroughs in Human Collaboration”?<\/a><\/li>\n
2. Evolutionary Context of Organisational Structures<\/a><\/li>\n
What is a burn up chart?<\/a><\/li>\n
Agile Metrics – Running Tested Features<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
It all started while working as CTO (first-time though) at Skuola.net and attending the conference Codemotion Rome 2019, I was listening to Daiany Palacios talking about hers \u201cThe trap of averages. How to avoid it in software development estimates\u201d in particular about doing estimates using the Montecarlo method. That moment something triggered in me, like […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","footnotes":""},"categories":[50],"tags":[47,106,107,108,109,49],"aioseo_notices":[],"author_meta":{"display_name":"fabio","author_link":"https:\/\/fabiocicerchia.it\/author\/fabio"},"featured_img":null,"coauthors":[],"tax_additional":{"categories":{"linked":["Project Management<\/a>"],"unlinked":["Project Management<\/span>"]},"tags":{"linked":["agile<\/a>","development<\/a>","estimation<\/a>","management<\/a>","noestimate<\/a>","project management<\/a>"],"unlinked":["agile<\/span>","development<\/span>","estimation<\/span>","management<\/span>","noestimate<\/span>","project management<\/span>"]}},"comment_count":"0","relative_dates":{"created":"Posted 4 years ago","modified":"Updated 4 years ago"},"absolute_dates":{"created":"Posted on December 1, 2019","modified":"Updated on December 1, 2019"},"absolute_dates_time":{"created":"Posted on December 1, 2019 12:45 pm","modified":"Updated on December 1, 2019 12:45 pm"},"featured_img_caption":"","series_order":"","_links":{"self":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts\/624"}],"collection":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/comments?post=624"}],"version-history":[{"count":0,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts\/624\/revisions"}],"wp:attachment":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/media?parent=624"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/categories?post=624"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/tags?post=624"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Colour<\/strong><\/td>\n	Description<\/strong><\/td>\n	Guiding Metaphor<\/strong><\/td>\n	Key Breakthroughs<\/strong><\/td>\n	Current Examples<\/strong><\/td>\n<\/tr>\n
RED<\/span><\/td>\n	Constant exercise of power by the chief to keep foot soldiers in line.<\/p>\n Highly reactive, short-term focus. Thrives in chaotic environments.<\/td>\n	Wolf pack<\/td>\n	\n \n Division of labour<\/li>\n Command authority<\/li>\n<\/ul>\n<\/td>\n	\n \n Organised crime<\/li>\n Street gangs<\/li>\n Tribal militias<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
AMBER<\/span><\/td>\n	Highly formal roles within a hierarchical pyramid.<\/p>\n Top-down command and control. Future is the repetition of the past.<\/td>\n	Army<\/td>\n	\n \n Formal roles (stable and scalable hierarchies)<\/li>\n Stable, replicable processes (long-term perspectives)<\/li>\n<\/ul>\n<\/td>\n	\n \n Catholic Church<\/li>\n Military<\/li>\n Most government organisations (public school systems, police departments)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
ORANGE<\/span><\/td>\n	Goal is to beat the competition, achieve profit and growth.<\/p>\n Management by objectives (command and control over what, freedom over how)<\/td>\n	Machine<\/td>\n	\n \n Innovation<\/li>\n Accountability<\/li>\n Meritocracy<\/li>\n<\/ul>\n<\/td>\n	\n \n Multinational companies<\/li>\n Investment banks<\/li>\n Charter schools<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
GREEN<\/span><\/td>\n	Focus on culture and empowerment to boost employee motivation.<\/p>\n Stakeholders replace shareholders as the primary purpose.<\/td>\n	Family<\/td>\n	\n \n Empowerment<\/li>\n Equalitarian management<\/li>\n Stakeholder model<\/li>\n<\/ul>\n<\/td>\n	\n \n Businesses that are known for idealistic practices (Ben & Jerry\u2019s, Southwest Airlines, Starbucks, Zappos)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
TEAL<\/span><\/td>\n	Self-management replaces the hierarchical pyramid.<\/p>\n Organisations are seen as living entities oriented towards realising their potential.<\/td>\n	Living organism<\/td>\n	\n \n Self-management<\/li>\n Wholeness<\/li>\n Evolutionary purpose<\/li>\n<\/ul>\n<\/td>\n	\n \n A few pioneering organisations (Patagonia, Buurtzorg, FAVI, Morning Star, ESBZ)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Source: Frederic Laloux, Reinventing Organizations [Nelson Parker, 2014]<\/div>\n <\/div>\n Check your organisation with the following assessment:\u00a0https:\/\/www.beyondteal.com\/teal-organizational-readiness-assessment<\/a><\/div>\n <\/div>\n \u2139\ufe0f Info: <\/strong>This estimation method is mostly applicable in red\/amber\/orange organisations.<\/div>\nNotes<\/h2>\n \n 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<\/a>.<\/li>\n I’ve tried this method with a fairly small team of 7 people.<\/li>\n<\/ul>\n The 4 Key Processes<\/h2>\n Sorting Process<\/h3>\n \n Use the Eisenhower Matrix<\/a> to group items together<\/li>\n Focus only on Urgent-Important, Urgent-Not Important,\u00a0Not Urgent-Important (in this order)\n \n Urgent-Important: We know we cannot do everything right now, so they\u2019re gonna be planned<\/li>\n Urgent-Not Important: It\u2019s just urgent postponable stuff, but unfortunately is “urgent”<\/li>\n Not Urgent-Important: Real schedulable\u00a0work<\/li>\n What about Not Urgent-Not Important: Let them stack up in the backlog, some day you\u2019ll prune…<\/li>\n<\/ul>\n<\/li>\n Within a sector order by priority\n \n Use any relevant metric: urgency, complexity, date, profitability, and so on<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n Estimation Process<\/h3>\n \n Get a prioritised tasklist following this order:\n \n Urgent-Important<\/li>\n Urgent-Not Important<\/li>\n Not Urgent-Important<\/li>\n<\/ol>\n<\/li>\n Do Affinity Grouping<\/a> based on the type of the activity: issues, task, enhancement, feature<\/li>\n Do your estimation of a task based on the historical data of how long in average it took based on the activity type\n \n 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<\/li>\n<\/ol>\n<\/li>\n Review with the team if the estimates sound roughly good enough<\/li>\n<\/ol>\n \u2139\ufe0f Info:<\/strong> Do have a look at No Estimates<\/a> since the concept is great, you’ll find more interesting topics that will help you.<\/div>\n \u2139\ufe0f Info:<\/strong> We are bad at estimating and each one takes into account his perspective. To be objective we need to be backed by data, even if it’s not precise.<\/div>\n\n \u2139\ufe0f Info:<\/strong> Try to gather as much data as possible about the historical lead time or worked time from project tracking tools by querying directly their internal database. For example, if you use self-hosted GitLab or Jira you can access their PostgreSQL database and harvest data.<\/div>\n<\/div>\n \u26a0\ufe0f Pay Attention:<\/strong> There should be no link between abstract units<\/a> (Fibonacci series, t-shirt sizes, and so on) and time. Remember that the management cares about time, it’s how human measure things. They will find a way to hack any framework to map it to working days.<\/div>\n \u26a0\ufe0f Pay Attention: <\/strong>Each team must have its own estimation (they cannot be mixed up) and they should be added together to obtain the final figure.<\/div>\nPlanning Process<\/h3>\n \n Use a Gantt Chart<\/a> to help you visualise the workload<\/li>\n Plan the work across different resources\n \n Plan at 70% capacity<\/a> (think about sick days, holidays, meetings, \u2026)<\/li>\n<\/ol>\n<\/li>\n Cut out whatever is not in the defined time span<\/li>\n Review with the team the Gantt Chart<\/li>\n<\/ol>\n You could use a schedule like the following one:<\/p>\n \n Monday – Thursday: work on urgent issues and scheduled work<\/li>\n Friday: work on support issues and repaying technical debt.<\/li>\n<\/ul>\n Execution Process<\/h3>\n \n Each week check the progress<\/li>\n Swap task assigned to resources whenever someone finishes all his\/her workload<\/li>\n Deliver each week part of the work, use a Feature Flag<\/a> approach to make sure you can control the impact of the functionality.<\/li>\n<\/ol>\n \u2139\ufe0f Remember: <\/strong>Agile is about fixed time and cost and flexible scope. For more details check the Quality Triangle<\/a>.<\/div>\n Pro & Cons<\/h2>\n Pro:<\/div>\n \n Quick estimates<\/li>\n Saving the time of the team<\/li>\n Enough precision<\/li>\n<\/ul>\n Cons:<\/div>\n \n Not enough precision<\/li>\n Requires constant checkpoints<\/li>\n<\/ul>\n Measuring<\/h2>\n 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:<\/p>\n \n It is Running, hence it has been released in production, creating value for the end-users.<\/li>\n It is Tested, meaning that it has been validated in different stages: unit testing, functional testing, integration testing and acceptance testing.<\/li>\n It is a Feature, meaning that has real value for the end-users.<\/li>\n<\/ul>\n 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.<\/p>\n Tools<\/h2>\n Use burn-up charts for better visibility of changes of scope (which happens all the time).<\/p>\n $\"burn$ <\/a><\/p>\n A burnup chart clearly shows both completed work and project scope. The project will be completed when the lines meet.<\/p><\/blockquote>\n 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.<\/p><\/blockquote>\n References<\/h2>\n \n The planning fallacy<\/a><\/li>\n ThrownEstimate<\/a><\/li>\n Underestimating Estimation<\/a><\/li>\n PurposeOfEstimation<\/a><\/li>\n Estimation is Evil<\/a><\/li>\n What to Do When You Miss a Deadline at Work<\/a><\/li>\n Moving Toward Teal Company\u2019s Workflow<\/a><\/li>\n Agile Antipattern: Everything is priority 1<\/a><\/li>\n DAKI \u2013 DROP, ADD, KEEP, IMPROVE<\/a><\/li>\n Web-Based Monte Carlo Simulation for Agile Estimation<\/a><\/li>\n Why Do Managers Hate Agile?<\/a><\/li>\n Aligning Workplace Learning to Organisational Paradigms<\/a><\/li>\n What are Laloux’s “Evolutionary Breakthroughs in Human Collaboration”?<\/a><\/li>\n 2. Evolutionary Context of Organisational Structures<\/a><\/li>\n What is a burn up chart?<\/a><\/li>\n Agile Metrics – Running Tested Features<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":" It all started while working as CTO (first-time though) at Skuola.net and attending the conference Codemotion Rome 2019, I was listening to Daiany Palacios talking about hers \u201cThe trap of averages. How to avoid it in software development estimates\u201d in particular about doing estimates using the Montecarlo method. That moment something triggered in me, like […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","footnotes":""},"categories":[50],"tags":[47,106,107,108,109,49],"aioseo_notices":[],"author_meta":{"display_name":"fabio","author_link":"https:\/\/fabiocicerchia.it\/author\/fabio"},"featured_img":null,"coauthors":[],"tax_additional":{"categories":{"linked":["Project Management<\/a>"],"unlinked":["Project Management<\/span>"]},"tags":{"linked":["agile<\/a>","development<\/a>","estimation<\/a>","management<\/a>","noestimate<\/a>","project management<\/a>"],"unlinked":["agile<\/span>","development<\/span>","estimation<\/span>","management<\/span>","noestimate<\/span>","project management<\/span>"]}},"comment_count":"0","relative_dates":{"created":"Posted 4 years ago","modified":"Updated 4 years ago"},"absolute_dates":{"created":"Posted on December 1, 2019","modified":"Updated on December 1, 2019"},"absolute_dates_time":{"created":"Posted on December 1, 2019 12:45 pm","modified":"Updated on December 1, 2019 12:45 pm"},"featured_img_caption":"","series_order":"","_links":{"self":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts\/624"}],"collection":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/comments?post=624"}],"version-history":[{"count":0,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts\/624\/revisions"}],"wp:attachment":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/media?parent=624"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/categories?post=624"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/tags?post=624"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

The 4 Key Processes<\/h2>\n