Story Points Are Dead; Long Live Story Points.

Predictability fosters trust and lowers coordination costs. It's crucial for scaling companies to handle growing cross-team complexities and maintain quality. Delays in projects often lead to challenges in quality due to tight deadlines, team burnout, and reduced flexibility.

The problem with story points

Story pointing is a common approach to promote predictability. Story points are great for decoupling an engineer's work estimate from how long a task might actually take, creating a simplified approach. However, they are not without drawbacks:

• Engineer Overhead - They demand additional overhead and can be confusing, especially for engineers new to the concept. Also, even items that don’t require predictability need story points to maintain an understanding of a team’s velocity.

• Management Misuse - There's a risk of misuse by management as a measure of productivity.

• Broader Scope Limitations - They are less effective for larger, ambiguous topics, performing best with detailed, lower-level tasks.

• Varying Velocity - In teams with seasonal stressors, story point velocity may not accurately keep up with the real work pace.

• Complex Extensibility - As project manager, given the abstraction from real time estimates, it can be hard to extend the process to meet unique situations.

Reverting back to real time estimates

I’ve found that thoughtfully using real estimates, with a few key supporting processes drives less overhead with similar predictability. Here are some examples:

But where did “2 eng x 3 days” come from? It came from a quick conversation with engineers on the team. The bigger the approximate scope, the longer the conversation. For the large work item above, you’ll likely need several hours of pairing to get to that first coarse estimate.

Tip: To increase estimate accuracy, look for similar recently completed work.

But how do we use these estimates?

You can take these estimates and feed them into an overarching management system with varying sizes of accuracy and time horizon. Next, we’ll put those estimates to work inside an example system.

Putting the estimates the work

Generally I find that estimates are used to answer one of the following questions:

1. When will the team start work?

2. What big ticket items will the team get done this quarter?

3. When should we coordinate this work’s release? (soft deadline)

4. We need this work done by March 1st. How should we approach it? (hard deadline)

Question 1 - When will the team start work?

Scenario - In a cross-matrix organization, product managers and designers often concentrate on upcoming tasks. They need to know when new work can begin so they can prepare without slowing down development.

Strategy - Monitor your team's plans for the next 4-6 weeks, aiming for realistic yet slightly optimistic projections. Review all the team's tasks and lay them out. It's good to keep a simple roadmap of upcoming work with estimated completion dates. Remember, these dates are flexible and subject to change. While project management tools are useful, the adaptability of whiteboard tools like Figjam and Miro is essential for accurately depicting real-time complexities.

In the example above, the product and design team have until 2/12 until engineers will begin to pick up work defined within phase 1.

Question 2 - What big ticket items will the team get done this quarter?

Scenario - As a company scales, there will always be competing priorities. These can include things like increasing revenue, decreasing risk, and increasing team velocity. A quarterly planning process helps ensure that the team’s investments are balanced between those priorities.

Strategy - Set up key buffers to ensure your rough quarterly estimates don't push the team into overworking. Consider these buffers:

• On-call workload

• Vacation and hiring

• Work outside the roadmap

• Extra time for unexpected scope in roadmap items

Here’s an example for better illustration of the idea.

Given a team of size 6, we can hold the following things to be true:

• There will be one engineer on-call at all times.

• We should expect all engineers to take one week of vacation, that’s 6 weeks or 50% of an engineer.

• There is non-roadmap level work beyond the quarterly roadmap which will occupy some engineering time. For this example, any given week there’s a 50% chance that they need to dedicate one engineer to non-roadmap work so we’ll consider this 50% of an engineer.

Ok Great! So what we’re saying is that this 6 person team actually has a 4 engineer capacity towards roadmap item work.

But we’re not done.

We still need to buffer for missed roadmap item scope. In this example, the organization generally finds that their coarse quarterly estimate strategies uncover only 75% of the work, so they block out 25% of the quarter. In other words, a 12 week quarter should really be viewed as a 9 week quarter.

Now let’s put it all together into a quarterly allocation view:

Next let’s take the three example work items from above and plot them on the quarterly allocation view:

In this case, at first glance, the team might seem a bit over-planned since the Outbound Engagement task extends into the planning buffer. However, this is balanced out by two engineers working on Outbound Engagement simultaneously with the Event API. This parallel approach increases the chances of completing all three work items within the quarter.

Technically, the team is under-allocated by about one engineering week, but for this level of estimation, it's best to consider it as "fully allocated with a small buffer."

Caveat: In reality, I’d recommend that you break down the Outbound Engagement work into multiple deliverables. Having the team work for 2 months straight without realizing value is an anti-pattern you should avoid whenever possible.

Question 3 - When should we coordinate this work’s release? (soft deadline)

Let's consider the example where the Outbound Engagement task involves complex release coordination. Depending on the specifics of this coordination, the team might use the end of the quarter as a flexible deadline, gradually increasing coordination meetings as the quarter progresses. By the second month, the team will likely have a better grasp of the work and can adjust the initial "end of quarter" release target based on new insights from their team and others involved. In summary, if this were Q1, the team could say, "We're aiming for a 4/1 release date, but since we're early in our execution, let's have a cross-team check-in on 2/1 to assess progress and update our plans."

Question 4 - We need this work done by March 1st. How should we approach it? (hard deadline)

Hard deadlines are often unavoidable, and external coordination can be greatly streamlined with firm deadlines when everyone involved is accountable.

In this case, let's say the Outbound Engagement project has a deadline of 3/1. With only four engineers allocated to roadmap tasks, everything would need to proceed precisely as planned (4 engineers for 6-8 weeks) to meet the deadline. This approach is too risky. The team should consider ways to deliver the essential requirements by 3/1, planning to address additional work later in the quarter. This doesn't mean abandoning the feature after 3/1. Instead, it involves making temporary compromises to meet the hard deadline, followed by swift corrective actions.

Let's assume the tradeoff involves manually initiating processes daily until automation is built, consuming 50% of an engineer's time until completion. With this adjustment, their revised view of quarterly allocation would now be as follows:

In this updated view, I've included "New TOIL" to account for the loss of approximately one engineering week due to the manual processes required until automation is completed. Considering our original estimate included a small buffer, we can still expect all three items to be completed as planned.

Retro at the end of quarter

If you adopt this approach, make sure to conduct a retrospective at the quarter's end to inform your next planning cycle. Ask yourself: What did we learn? Were the buffers adequate? Were the roadmap items more complex than anticipated?

Summary

As you become more familiar with this method, you might notice it resembles story points, and you're not mistaken. These time estimates are not strict calendar dates but rather a point system designed to minimize engineers' overhead. I believe using actual time values in the estimation system enables those making the estimates to demonstrate their reasoning more effectively than with story points. This approach allows for better adjustment and learning, as teams and organizations are always evolving.

In summary, this method simplifies the learning process for individual engineers but adds complexity for the management team. Personally, I favor this trade-off, though experiences may differ.