In traditional waterfall style #projectmanagement, a #projectmanager will invest a great deal of time attempting to work out the scope of a #project as well as the anticipated timelines for delivery.  

It works well in complicated environments like civil engineering because both civil engineers and project managers have built heaps of roads and bridges and have a fairly accurate idea of how long something will take.  

In complex environments, it's a great deal more difficult to estimate time because often, what is being built has never been built before. The problem that needs to be solved has never been encountered before and it's incredibly difficult to estimate a time for delivery because of that.  

So, how do the #developmentteam estimate time in a #productdevelopment environment? How do they estimate how long something will take to deliver if they have never encountered the problem before?  

The truth is, they don't estimate time at all. They estimate the amount of work and effort that is required to deliver the backlog item.  

The team will discuss each item with the #productowner and based on their expertise and experience, make an educated guess of how difficult something is to complete and use a number to estimate the size of the task.  

For some teams, that could be shirt sizes such as Xtra Small or Large whilst other teams use planning poker and a fibonnacci sequence to demonstrate how much effort is required in relation to something else.  

Turns out we are relatively good and accurate at estimating the size of the problem or task at hand whilst we aren't great at estimating how much time it will take.  

In an #agile environment, teams also use #sprint #burndowncharts to track progress of work versus time taken to completed and over time, the data from those charts can help form a reasonable estimate of how much work can be completed in a given #sprint.  

A #burnup chart does the same thing. It provides insights into how much work has been completed in a given period of time and will enable the team to reliably estimate how many points they can deliver within an average sprint.  

So, why is it so difficult to estimate time in a product development environment?  We asked John McFadyen for his perspective and his answers are contained in this short video.  

John McFadyen has worked in some of the highest performing #scrum teams in the world as both a #scrummaster and #agilecoach. He has also worked at the coalface of some of the UK and Europe's largest, most complex #agiletransformations.  

If you like the idea of becoming a Scrum Master, visit our Certified Scrum Master course page on https://www.agilecentre.com/courses/scrum-master/certified-scrummaster/ 

If you are already a scrum master and want to upskill, visit our Advanced Certified Scrum Master course page on https://www.agilecentre.com/courses/scrum-master/advanced-certified-scrummaster/ 

If you have several years' experience as a scrum master and want to both validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master course page on https://www.agilecentre.com/courses/scrum-master/certified-scrum-professional-scrum-master/ 

If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy on https://www.agilecentre.com/courses/agile-coach/agile-coach-academy/ 

If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction to Coaching course page on https://academy.agilecentre.com/courses/introduction-to-coaching 

For more information on John McFadyen, visit https://www.johnmcfadyen.com #agile #scrum #projectmanagement #productdevelopment #agileprojectmanagement #scrummaster #developmentteam #productowner #estimation #estimatingwork