One of the things that Sprint.ly actively eschews is the notion of time. This can be a bit jarring to more traditional Agile/Scrum shops, but we have our reasons. First off, let's look at the time-related things that are not present in Sprint.ly.
- Estimating tasks in hours.
- Estimating tasks in points.
- Milestones based on a date.
- Time boxed sprints.
"Prediction is very difficult, especially if it's about the future." – Niels Bohr
There are two traditional ways of estimating tasks across all paradigms: hours or "effort" hours and story points. We think both have significant flaws. Estimating time is an extremely difficult, high cognitive load for humans. The reality is that human perception of duration is both subjective and variable. There is a significant body of psychological work that indicates that humans, quite simply, have no idea how long things are going to take. This is particularly obvious to parents who've taken their children on road trips. For this reason, we have completely removed the notion of time estimation.
Agile/Scrum recognized this shortcoming of humans and introduced "points" as an estimation paradigm. Points were supposed to be based on three main factors: complexity, doubt, and effort. While we think that points were a noble effort, we've found they're too abstract for most people to understand. Many developers don't know what points are so, surely, very few of the business, or customer support, folks will know what they mean or how they affect timelines.
Milestones, Sprints, and Time Boxing
Over the years we've created a few thousand milestones and time-boxed sprints. The reality is that it was a complete and utter waste of time. We know we are lying to ourselves every time we enter a date and associate tasks with that date. We actually polled every product manager, developer manager, VP of Engineering, etc. that we knew and asked them a simple question: Have you ever seen a date hit as originally spec'd? Their answers varied from laughter to more laughter.
The reason for this is simple: products are either date-driven or feature-driven. In other words, you'll either sacrifice features to hit your date or you'll let your date slip to ensure all features are launched.
This insanity needs to stop. We're lying to ourselves, our employees, our investors, our board members, and, most importantly, our customers by suggesting dates we know are based, at best, on conjecture.