Past Velocity and Prediction

I don’t know about you — but when you talk about stocks, or markets, or funds — the general rule of thumb is:

Past performance is not an indicator of future outcomes.

Have you noticed that is software engineering, we tend to ignore this advice? We tend to use our current velocity to calculate our next velocity and our future velocities. We like to look at past performance to determine what we can achieve within the next sprint/quarter/year. Why do we ignore this commonly accepted rule of thumb from finance? Are humans and our efforts really more predictable than a market? I don’t think so — but I’ll dig deeper.

Recording Velocity

One of the things you’ll find most “agile” teams doing is recording velocity. If it’s not the team, it’ll be the PO (Product Owner). It’s their job to give some security to a business and be able to say what they think they can achieve while minimizing risk. Velocity is normally (from experience) regarded as the number of story points your team can get “done” in a sprint. Basically, you record this over time to get to a point where you can predict what the deal will be able to achieve next sprint (and beyond).

P.S. I put done in quotes because every team’s definition of done is different. Your team needs to figure this out for yourself. Some previous definition of done’s I’ve had are:

• Merged to master.
• QA tested.
• Deployed to live.
• Development finished.

Story points?

Story points are very rough estimates of the required effort for a story. They should never be associated with a time. Obviously, there are exceptions to every rule. When you’re first estimating, you’ll probably end up using days. But it should not be a direct one-to-one conversion. Generally, I’ve used T-Shirt size estimates and sometimes they have numbers associated with those sizes. You add up all your story points done and that will give you the velocity for that week.

• XS, S, M, L (after large, the stories should be broken up), XL, XXL, XXXL etc.
• 1, 2, 3, 5, 7, 13, etc.

Is Velocity Meaningful?

Normally, when a member joins a team (or leaves), it’ll probably take around 6 months for velocity to stabilize. Why’s that? Because it takes a long time for a team to build trust and to measure their performance accurately for their products. So, while you can record velocity, it probably won’t mean anything until your team builds the trust. That said, it is good to keep at it during this first six months to build up the trust in the numbers. But can you ever trust the numbers completely? They’re just rough guides remember. Some stories might have hidden complexity. Over time, your team will figure this out and your estimates will improve.

Using Velocity — what does it mean?

You can’t compare two teams’ velocities. It just won’t work. One team may underestimate and one team may overestimate. Story points will have different meanings for the teams. So why would you even use them? In my team at Agoda, rather than the PO (Product Owner) say what will be completed in a quarter to management, we work with the PO to determine our past quarter’s velocity and can use that to give an approximation of what we’ll get done next quarter. This means that you have ample stories in the backlog estimated.

Now, this does not mean that you’ll work day and night to complete what you committed to. No. This means that you can manage expectations of management and the team. PO’s are always coming up with ideas and changing plans. Guess what? You can (based on your estimates) kick stories out of your commitments if your PO changes plans all the time. You can say “if you add this story — it will probably remove the bottom two from the quarterly goals. Are you okay with that?”. The PO will most likely answer yes and you aren’t stuck with unmanageable goals.

To Sum it All Up

Velocity is a funny metric that cannot be consistent across an organisation. You can try to use velocity to predict future commitments and/or sprints, but that doesn’t mean that it’ll be 100% accurate. Plans change all the time. People will come and go from your teams. However, it can be useful to roughly predict what features you might want to include and how to prioritise them. You should use story points and not time to base your estimates. Story points should not be related to time, but to effort. Lastly, figure out what your “done” is.

Originally published at www.alexaitken.nz on July 9, 2018.