How does your team plan?

It depends.

A longer TL;DR answer — The use of story point estimation is situational. Not every team benefits from a process as heavy as point-based estimation. Points are used to keep a team accountable for what they are meant to deliver and their velocity for delivery.

Examine Your Situation

Whether or not you are using points, the question for most engineering teams is: are you delivering what is expected in the time that is expected?

So my question back to my PM friend was, is your team delivering as expected, or are they missing the mark?

Turns out, his team is in a classic situation: they are using point-based estimation, but they are constantly missing their delivery goals. So, regardless of your estimation system, here are a few questions to ask yourself as a manager when you are in this situation:

  1. Is your team truly accounting for everything they are working on in a given sprint?
  2. Is your team estimating correctly?
  3. Is your team underdelivering?

These are three separate problems. For this write-up, I will focus on diagnosing the problems and give suggestions on how to fix the problem. I am going to assume you have heard of things like agile, Kanban, waterfall and have some familiarity with what those are. If not, check out the topics on the internet.

Before we get started, a few notes on process:

Don’t adopt the process just because you think you need a process (see https://agilemanifesto.org/ ). Find out your problems and adopt a method that fits your team’s needs. If a process is not working, adjust it. Don’t be afraid to try new things. Throw the process out if you have to. On the flip side, if a process doesn’t work, check you are using it correctly. Don’t write off all processes as a waste of time. A good process is designed to cut the crap and provide structure in ambiguous situations.

On the first engineering team I managed, we needed points. Adopting that system helped our team. We had multiple projects with multiple product and technical stakeholders; we owned multiple codebases, and we had a high operational support load, requiring two full-time engineers to keep the lights on for the services we owned. With so much to be accountable for, points offered a very structured process to ensure we prioritized our resources.

My current team would not benefit from points at all. Why? Because our team is accountable for less. In the last six months, we were focused on three core projects. We have one PM. Our team rarely fields external requests for urgent work. On the whole, our operational support load can be maintained without cutting into sprint time. Adopting a pointing process would be cumbersome and waste two hours of team time every week with a very expensive meeting. This could always change. As your team changes, you should adopt new practices to fit your needs.

Back to blog

Leave a comment