This is the twelfth 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

Let’s talk about estimates and story points.

What’s that?

Story Points represent the complexity, risk, effort, and scope of a user story. They are not just a measure of “effort” or any other single dimension — they must include all of those. You estimate your stories with story points to get a relative size of each of them, so then you can plan the longer future (we’ll cover that in some other post). However, once you start planning your iteration, you need to break a user story into tasks. How to do that?

Let’s say that you divide stories into tasks which are at most one day long. However, some dimensions may be accidentally constrained and hidden. If you do that, then you effectively remove “effort” from the SP estimate as each task is based on an exactly one day of effort. That’s not what you want to do.

But what is “effort” and should it be linear? That’s a good question. You may have a story which is simple, risk-free, non-complex, but will take a lot of time — like writing a documentation or fixing the formatting in a document. In that case, the story should have few SPs, but might still take much longer time than some other coding story which is very risky. On the other hand, if instead of “writing a documentation” you have a story about “writing 3 documentations”, then it shouldn’t have 3 times more SPs — the effort is higher, but other dimensions remained the same, so there should be no linear increase. No to mention that the complexity increases with more and more subparts.

How to divide stories into tasks then? Some people (for instance, Mike Cohn in his Agile Estimating and Planning) suggest that tasks should be “doable in a day”. However, instead of thinking in terms of “task doable in a day”, think in terms of forcing multiply — if you can parallelize some work, then it should be split into multiple tasks. If you cannot, and there is no logical “checkpoint” in it, then it should be a single task. If it takes one day — that’s great. But if it takes three days — that’s still okay. Technically, a task (and a story) must be doable in a sprint, that’s the only requirement. However, if it’s expected to take more than a half of the sprint, then it’s probably wrong.

Capacity, velocity and other stuff

Okay, so we broke down stories into tasks. Now, how do we know which stories should we include for the upcoming iteration?

One idea is that you can calculate the capacity and velocity for your team, especially, if the team is stable. That can give you some idea how much time a work will take, based on some previous sprints. However, as soon as you start doing something with capacity/velocity to plan the future, you miss all the point. When you plan a sprint then you need to commit to a work — you need to believe that you’ll finish all the tasks in a given sprint. I’m making an important assumption here — you either do your stories completely, or you don’t include them in the sprint. However, to do that you need to use time estimates, not story points. Some teams use story points for estimating their tasks, and I believe it’s wrong. And here is why.

Let’s say that you are on a team of 5, the team is stable, and in the last sprint you worked on 25 stories, each estimated to 1 SP. You generally know your stuff, you work in a known domain, you don’t take vacations etc. So, now the next sprint planning comes, and you have tasks estimated to 3 SP each. How many of them can you commit to? If you think 8, then it indicates that you use SPs as a yet another unit of time measurement, and that your estimates grow linearly. That’s not correct, three one-pointers do not make one three-pointer in terms of time (because there are other factors included in story points estimation). However, there is a yet another issue with this approach — in the previous sprint everyone worked on five one-pointers, so we could argue that their capacity was 5 SPs each. So, why do you plan to take eight three-pointers if – by the pigeonhole principle – there will be someone taking at least two three-pointers for the sprint? That indicates that there must be someone with a capacity of at least 6. This just doesn’t add up.

You could argue that they’ll just start the task, and have some carryover brought to the next sprint — but that’s against the idea of planning and commitment. Agile approach wants to tackle the uncertainty and risk, but doesn’t want to get rid of planning and commitments. Programmers argue that they can’t predict in advance nor estimate things for the months to come, so they want to plan small increments. However, they still need to commit to the work they will complete in the sprint. If you take a task and commit to “I won’t finish it but I’ll at least start”, then you’re doing it wrong. You should split the task into parts, and take one part which you can complete in the sprint. Agile approach and story points are not for avoiding the time estimates completely, but for making them more realistic and reliable. You still need to commit to a work done in the sprint, and this means that you commit to some timeframe because you know how long the sprint will take.

Instead of 8 three-pointers you should probably take 5 of them. It’s a big difference if you take 15 SPs in total versus 25 SPs in total. That’s 40% or 60% difference (depending what your baseline is). And this is the reason why a team can deliver different number of SPs in each sprint — it’s not about the reality that sometimes three-pointer takes a week and sometimes takes two weeks. It’s about committing to a different number of SPs! However, if you know in advance how many SPs you’ll commit to in the sprint planning, then it’s completely against the idea of SPs.

This all goes down to one conclusion — you can calculate capacity and velocity. However, as soon as you start using these values to plan your single sprint work, then it’s all wrong. Story Point is not another unit for measuring the time. SP is completely different, and if you can provide an algorithm for reducing it to the time, then you’re just estimating in a different time unit. So how do we go from SPs to time? The short answer is — we can’t. We can only commit to the work delivered in the current sprint. SPs can be correlated with time estimates, but they can’t dictate them nor time estimates can be deduced from SPs.

But I need time!

But we need time estimates. We need them to plan our work in advance, right?

Yes, that’s correct. And here’s why I think estimating tasks in SPs is bad. Programmers differ — they have different experience, different skills, they like different parts of SDLC. You can’t just come up with simple coefficient to translate SPs into hours as each sprint is different and each programmer is different, so you should know these coefficients per person and with knowing the future (as they change with each sprint). Because of that, it’s super simple for a programmer to have an explanation why he worked on a task for “too long” — that’s because SPs do not convey any time estimate (apart from the commitment to a single sprint).

But stakeholders need to know how long things are going to take. First, because they want to plan their budgets in advance. Second, because multiple other things need to be coordinated (marketing, commercials, sales, etc.). Third, because if some projects are going to take too long, then they should be killed.

Since programmers are often uninterested in non-technical stuff, they want to get rid of the responsibility. And that’s why they like estimating tasks in SPs — they don’t need to think about hours, and have a very good explanation that things will be done “when they’re done”. This is obviously very limiting, and good engineers understand that. If you think that it’s okay that programmers estimate tasks in SPs, then imagine a situation that your plumber tells you that fixing your plumbing “will take 8 SPs”. How do you know how long it’s going to take? You don’t, and it’s your responsibility to take the risk. Obviously, you don’t let your plumber give you estimates in SPs, but you expect time estimates instead. Oddly enough, programmers often claim that software engineering is different than the “real life”, and so they can’t estimate in time over a longer period of time. That’s not true but we’ll get to that some other day.

So how should it look like?

Once you break down stories into tasks, you estimate each task in hours (or days, or whatever other time unit). Then, you just do your math to check which tasks you can take into the iteration. And based on that you commit to which user stories you’ll deliver.