Complexity Drives Effort

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.

'As a' as stakeholder, not actor

Dear Junior

The story format ‘As a <> I want <> so that <>’ is quite well established within the agile sphere by now, and almost the standard format in Scrum. In a way it is a pity because even though I like the format, and use it myself extensively, almost exclusively, there is a risk that we are setting in the mould. I have even heard equivalents of “if you are not doing asaiwantsothat, you are not agile”. I think we should be doing more experimentation, we should be avant-garde, not dogma. Nevertheless, well established as it is, I think it is misunderstood.

Old habits die slowly, and so old mental models. One old mental model is the one of the “use-case”, where some actor performs some action, and the system reacts in some described way. The format ‘As a <> I want <> so that <>’ can be used to describe a use case by inserting the actor in the as-a-clause “As a(n) <actor> I want …”, where the I-want-clause often takes the form of “be able to <GUI-enabled feature>”. My point is that even if the format can be used in this way, it is not limited to that usage.

If we use the format to express enterprise value, we can express things like ‘As a head of accounting department, I want nightly synchronizations and comparisons with our bank accounts, so that we early can catch failed sales”. Barring that we know little about ‘synchronizations with bank’ or ‘failed sales’, we can see that this is not a use-case: the as-a is not the actor, it is the person feeling the pain of this functionality lacking, and based on this way of expressing the story, it will be much easier to get the Head of Accounting to sponsor and promote the story.

Opening up this door we see that there are multiple ways to address other difficult stories. Expressing quality characteristics (aka non-functional requirements) can be done in the same was “As a marketing manager, I want the system to be able to handle 100 000 new users registering the same evening, so that it does not break down when we run our successful advertising campaigns”. You can also express ‘tech stories’ “As a QA manager, I want the system to be put under continuous build with the tests run automatically, so that we early know if a quality problem arises”. You can even express ‘soft issues’ like training “As a Development Manager, I want all team members to get basic training on version control so that we get rid of all those merge-mistakes that we suffer “. In all these examples, we have a stakeholder expressing something that would give enterprise value to their aspect of the development effort, thus something a team could estimate in effort and a product owner could prioritize.

Of course, we can now notice that the ‘actor’ interpretation is just a special case where the stakeholder happens to be an end-user of the system.

When working with this format I have also found it helpful to drop the ‘a’ in ‘As a’. Phrasing it “As Head of …” makes it a little more succinct, and seems to give the stakeholder him/her-self a more direct bond when reading it. Phrasing it “As a Head of …” seems to be a little bit more ‘distant’ or ‘observing’ way, and does not (in my humble experience) to catch on in the same way.

So, obviously we are nowhere near the perfect format for “requirements”, we should not restrict our formats unnecessarily, we should look for new way of using those we have, and we should definitely do more experimentation.

Yours

Dan

ps Mike Cohn has written some related blogs and was kind enough to point me too them. Check out Non-functional Requirements as User Stories, Advantages of the “As a user, I want” user story template, and Writing User Stories for Back-end Systems that muse on adjacent themes.