Dear Junior
There has been a recent discussion on story point estimation (or sizing) that is so common in Scrum. Especially the discussion has been about how sizes should relate to complexity and to effort needed to complete story. In a blog post Mike Cohn made a good example between effort and complexity by comparing "licking a thousand stamps" on one side, and "performing a simple brain surgery" on the other side. These where assumed to take approximately the same effort, but had drastically different complexity. Point was that they should have same amount of story points.
It is Effort that Makes a Difference
I think there is a lot of merit to the point Mike makes that it is amount of effort that is the usable parameter - we need it to make rough cost estimates and to predict what functionality can plausibly be released when. Complexity is not usable in the same way.
However, even if "effort" is what we primary care about, to me complexity plays a very central role - more than I have seen mentioned in the discussion. To clarify I would like to dive into the thousand-stamps-example.
Story is Effect, not Task
To start with, the team should not get a story saying: "lick a thousand stamps"; because that prescribes a specific solution. A good story should only point out the desirable effect, and leave to the team to pick a good solution. I guess the story could instead have read: "ensure a thousand stamps get licked", or something along that line. The difference is subtle but important. In the first case, the team is given a task to perform. In the second case, the team is given a problem to be solved.
Bulk Driving Effort
If you are to lick ten or a hundred stamps, you will certainly just do it. If you are to lick a thousand you will get mighty bored and tired - with ten seconds per stamp that amounts to three hours of work. However, it is still manageble, so you just get onto it. So here the effort will be driven by the bulk of the job - more stamps, more effort.
However, if you are to lick ten thousand stamps, or a million, then you are facing another magnitude of effort. To lick a million stamps would take 10 000 000 seconds, which is 70 weeks of full-time work - the better part of two years. Facing that task I would probably start building a stamp-licking machine.
Interesting enough this changes the game. The effort of building such a machine is independent of the amount of stamps to be licked. It is roughly as hard to build such a machine whether it will lick thousand or ten million stamps. So, bulk does no longer drive the effort.
Complexity Driving Effort
So, how hard is it to build a stamp-licking machine. Well, the actions involved is pretty straight forward, there are only one set of maneuvers, and no decisions to make - so, not-too-hard is a fair guess.
And here comes the other half of the interesting change of the game. The effort is decided by how hard it is to build such a machine - i e the complexity of the task. So, bulk does not drive effort any longer, instead it is the complexity of the task that drives the effort.
Software Development Teams do not do Bulk
Going back to software domain, the equivalent of licking lots of stamps (10 seconds each) is probably to send a pre-formatted mail to a long list of email addresses found in an excel sheet ("new mail", CnP mail content from template, CnP email from next line in sheet, "send").
A team of developers given the story "send mail to top thousand customers" would certainly not open Outlook and start at top of list. Instead they would write some script that generates a mail to mailer daemon given the to-addr - effort 15 min. Then they would write another script that loops over a text-file with email addresses and sends same mail to all of them using first script - another 15 min. Last, they would export the mail addresses from the excel sheet to a file, feed it to the looping script, and off we go - another 10 min. OK, let us allow for extensive testing and coffee break but we are still around two hours.
Complexity Drives Effort
The important point here is not whether the script-solution would be faster or not. The important point is that the effort needed is not determined by the size of the batch. The effort needed is determined by how hard the problem is to solve - how much time must be spent discussing design, how tricky it is to get right in coding, how much testing is needed to feel confidence in the solution. In other words, its complexity.
The effort which we need to put in to solve a problem in software development is very much a function of the complexity of the problem. The complexity can be essential to the problem, i e if we are working in a knowledge-intensive domain. This is of course the call for Domain-Driven Design. The complexity can also be accidental, e g if we have an over-complex architecture or a codebase in bad shape. This is of course the call for software craftsmanship.
Disregarding the reason, overcoming said complexity will be what decides whether we need to spend a lot of effort or not.
Sizing, or estimating, in story points should definitely reflect the amount of effort we think we need to put in. However, in most cases it is the underlying complexity - essential or accidental - that drives that effort.
Yours
Dan
Ps On of the reasons why complexity of problem is so central is that software development to a large degree is a knowledge journey.
pps It is easy to be fooled into discussing what "story points really are", but from a pragmatic view that is uninteresting, unless it makes a difference. What matters is "what story points are useful for", i e the point of story points.
pps It is easy to be fooled into discussing what "story points really are", but from a pragmatic view that is uninteresting, unless it makes a difference. What matters is "what story points are useful for", i e the point of story points.