This is the thirteenth part of the Types and Programming Languages series. For your convenience you can find other parts in the table of contents in Part 1 — Do not return in finally

Last time we covered a case of story points. I mentioned that it is possible to estimate in time units over a longer period of time. In this post we’ll see a couple of ways how to do that.

Capacity and increments

Before getting to actual time units, we’ll cover capacity. I mentioned that you can’t use capacity to plan your sprint — if you know in advance how many story points you want to take to the sprint, then you’re doing it wrong. Sprints are for committing which user stories will be done completely, and the actual number of story points will differ from sprint to sprint.

However, when your team is stable, then you can calculate the capacity, and use it to assess if you have enough work planned for some period of time — the next release. That’s just a practical case — business analysis is expensive and takes time. Also, plans do change over time, and there is no point in planning something for 3 years from now because most likely it will get out of date. At the same time, you want to have some idea how much of work is ahead of you, and what you’ll be working on over next 6 months. That’s why you need to balance how often you perform the business analysis, and if you should do it now, or if it can wait. And that’s where you use capacity.

If you calculate that on average the team delivers X story points in a sprint, then you can check your backlog, and see how much of it is estimated, and if it’s enough to fill the work for the next release. Here you just multiply the capacity by the number of sprints until the release, and you check if you have enough stories. It’s not about being super precise, but about having an idea how long things are going to take. If you see that you have enough story points to fill your work for the next year, then there is no need to do the business analysis with your client now, as it can wait until the next month. And it goes the opposite — if you think you have enough work for the next 6 months, but then it happens that it was enough for 5 months only, then it’s still okay. You’ll react later on the way when you notice that you can’t plan another release in advance.

The feedback loop

Okay, so is this for release planning only? No, it’s not. Story points are used to measure your work in a relative way. You need to compare things with each other, and be able to tell which things are “big”, and which are “small”. This must be done in a loop, and include all the parties.

The way you do it is as follows: first, the client indicates what needs to be done. We then need to run a business analysis with the client to get some details, break the work down into user stories. Next, software engineers need to get together and estimate the work with story points. They are not supposed to estimate the exact length in hours/days/months. They only need to show which tasks are big and small.

Next, you take these estimates to the client again, so they can decide the priorities. The client may not be aware, that a feature is big in terms of technical complexity, even though it seems small in terms of the outcome for the client – measured in the amount of visible UI changes, simplification, performance improvement, or whatever else. That’s why you need story points, so the client can adjust the priorities, and indicate which things should be done first, and which things can be postponed or dropped.

Finally, the backlog is ordered by the client. Next, engineering teams get together and plan the sprint. At this point you drop the notion of story points, but break down user stories into tasks, and commit to specific user stories to be delivered in the sprint. And this was covered in the last part.

Planning in time units

So here we get to an important conclusion. If you use capacity to calculate if you have enough work for next 6 months, then you’re effectively using story points as a time unit. And in this case this is okay — because it’s only a prediction, not a commitment, nor rule which user stories to commit to. But now it may seem like we returned to a waterfall model, didn’t we? No, we did not, because we adjust the process on the way. In the waterfall we first analyze the work, then we do the implementation, then we test it, and then we deploy. That’s it. With spiral (incremental, agile, whatever your name is) approach we work in terms of releases — we plan a much smaller part of the work, and deliver it completely. That’s why the software engineering is a bit different from building houses — you move in to the new house only after it’s complete. You don’t move in if it doesn’t have a roof or windows. However, with software engineering we start using the software even if it’s not complete yet, and we do it much earlier. And that’s the point of the incremental work — we don’t wait until the house is “done done”, we move in as soon as we have one room, with no windows, no ceiling, and no front doors.

However, we aren’t precise. We won’t estimate the one year work perfectly, we’ll always miss the deadline. But it’s a risk we take because we can fix our trajectory as we go. Things change — we may lose the technical advantage, we may lose the investor, people may leave the company, people may get hit by a bus. There are multiple things which can go wrong, so we just need to admit that we won’t be precise. But it’s not about realizing a year from now that we missed the deadline — it’s about figuring it out early, and being “precise enough”.

How to be precise enough?

History shows that experts’ estimates are just imprecise. We can limit work in progress, avoid crawling scope, reduce hidden work, avoid double-booking and repeated work to improve the process and get more reliable estimates. We can then use Monte Carlo, find critical paths and simulate different scenarios. But we can also just overbook our plans, and assume that 30% of them won’t be delivered in a year. It’s all acceptable as long as you know how imprecise you are.