Basecamp’s Ryan Singer articulates well the struggles with adopting and truly getting value out of an agile workflow. The core problem most teams face isn’t that they’re bad at estimating time to completion, it’s that they don’t even know what exactly they’re trying to complete. Knowing the broad outline of the objective — like “refactor user management interface” or “build dashboarding system” — is one thing, and the team could all largely agree on the target. But it’s another thing entirely to break down each step along the way into a discrete element with a clear beginning, end, and lane markers on either side.

In macro terms the team may know where the goal is, but along the way there are plenty of unknowns encountered on the path that throw wrenches into progress.

The idea in this post of the “hill chart” for visualizing the product development process is great. To me it represents reality much more accurately than simply perceiving work on a feature as “points” to be applied.

Typically, once you’re over this “hill of uncertainty”, estimation becomes realistic and useful. Getting into the “making it happen” state is where teams want to be:

Teams that track “velocity” and “story points” treat development as if it’s linear labor. Software development is not like moving a pile of stones.

If work was like that, you could count the stones, count the time to move one, do the math and be done.

Work that requires problem solving is more like a hill. There’s an uphill phase where you figure out what you’re doing. Then when you get to the top you can see down the other side and what it’ll take to finish.

Even if you take a large feature with a health dose of uncertainty, applying a “story point” quantity of 15 doesn’t really help the rest of the team grasp the stage in the cycle — you end up with a binary status: it’s either done or it’s not done yet.

When I think about the potential of this as it pertains to our team’s process, the soundest way to apply it is to think about everything left of the crest in the hill as happening in a “planning” stage, where we’re thinking through the implementation details, pros/cons, and risk/reward ahead of resource-heavy development. Creating specs, what-ifs, and wireframes as much as possible to lower the cost of reaching the top of the “hill of uncertainty”. Of course there’s no way to reach 100% certainly before writing code, but it avoids falling into that trap of jumping the gun before we’ve resolved the most obvious uncertainties.