There's an assumption that time is fungible in Agile planning which is sometimes true but often not true.
I worked on a project that usually had two week sprints, part of a sprint was running a batch job that took two days to build a database and machine learning model. It took more like 2 hours of labor to set up, but if you put off building the database as late as possible as everyone else on the team seemed to do, you could easily put it off until the last day in which case you blow the sprint. If I did it, I would start it very early (at least a week) because there was some possibility the job would crash or you found it was configured wrong.
Thus I learned there was a big difference between calendar time (complete the foundation of the the building by Feb 1 so the very expensive crane that arrives on Feb 1 c an go to work) and punchclock time (pay workers for 2500 hours of labor to build the foundation.)
PaulHoule|2 years ago
I worked on a project that usually had two week sprints, part of a sprint was running a batch job that took two days to build a database and machine learning model. It took more like 2 hours of labor to set up, but if you put off building the database as late as possible as everyone else on the team seemed to do, you could easily put it off until the last day in which case you blow the sprint. If I did it, I would start it very early (at least a week) because there was some possibility the job would crash or you found it was configured wrong.
Thus I learned there was a big difference between calendar time (complete the foundation of the the building by Feb 1 so the very expensive crane that arrives on Feb 1 c an go to work) and punchclock time (pay workers for 2500 hours of labor to build the foundation.)