Requirements, User Stories and Backlogs

User Stories, half of me hates them, that half of me wonders “What is all the fuss about?” and that half wonders “How did Mike Cohn write 200 pages about something so simple?”

The other half of me see that people find them useful. They fill a need. They contain the key elements of requirements “Who What Why.” And over the years I’ve built up a lot of advice I give to people and teams. Some of it is User Story specific, some is about requirements in general and some is about backlogs and Agile.

A couple of months ago I was flying to Dallas to see a client. Its a long flight from London so I took the opportunity to write down my standard advice. The other passengers must have thought me strange, for over half the flight I was tapping into my laptop. By the time we landed I had about 25 pages - yes 25! - of raw, unedited, material.

I’m in the process of turning this material into a series of articles for Agile Connection - and benefitting from the advice of Johanna Rothman as I do it. The first pieces are already online:

1. User Story Heuristics: Understanding Agile Requirements
2. Relieving Agile Tension: How to Write Small Stories That Still Have Value
3. Know Your Customers: They Can Help You Write Better User Stories

This series will stray into requirements and backlogs.

Now as it happens, about the time of Dallas flight the nice people form Libero in Romania asked me if I could give a day seminar on, yes, Agile Requirements. So, if you are in Romania, or fancy a trip to Romania in September check it out:

• Requirements, User Stories and Backlogs, 16 September 2015

Iterative or Incremental?

Hopefully most of my readers have noticed by now that I regularly stray from the Agile Gospel, or rather, I have a tendency to go against the common form of Agile. (And if you haven’t noticed you probably haven’t read My warped, crazy, wrong version of Agile post and its philosophical successor, Xanpan.)

Today I want to take issue with Iterative and Incremental, in particular the definitions of Iterative Development and Incremental Development used by Jeff Patton. It’s not that I think Jeff is wrong, its just that I use these terms differently and if you look closely Jeff and I use them in almost opposite ways. Seb Rose picked up on this a few years ago but recently I’ve had two or three e-mails form concerned readers but it was David Lowe’s blog that finally moved me to write.

I have long talked about “3 Styles of Agile”, one of these styles being Incremental and one being Iterative, to recap:

Iterative development occurs when the wider organization don’t care about Agile - or if they do they see it as something to make coders in the boiler room work faster. Consequently the team do good Agile stuff (stand-ups, iterations, TDD, refactoring, etc.) but they are working from a big old requirements document. In so much as they have a Product Owner the role is probably filled by a Business Analyst who has little authority, he operates a bacon slicer which turns the requirements document into small stories for development.

The organization wants all or nothing. They don’t care about early partial deliver. They may even see deviation from requirements as a problem because they still operate traditional governance (time, cost, features and/or compliance with a plan.)

Incremental development is fairly similar, the team do the good stuff but the organization doesn’t really care for Agile and probably still has traditional governance. However they team do make regular deliveries, at the very least they demo their latest creation and more likely they provide early versions for clients to use. As a result the benefit starts accruing far sooner but that also means they get extra requests for functionality and some stuff is removed.

Because they are delivering something, and because they are increasing the value delivered I call this incremental. It is increasing. In contrast an iterative team are basically running in tight loops. It better than the alternative but the business see no added value. However in doing this the team has created forces which will result in a future conflict - they accept change but governance does not.

So my model is clear?

(For a longer discussion see my Agile Spectrum piece from a few years back.)

Now Jeff Patton uses the two words differently. Jeff’s analogy is the Mona Lisa: A development team could paint the bottom left corner of the Mona Lisa perfectly, you would have a few square inches of perfect Mona Lisa and the rest of the canvas would be blank. Once that is done the team move to the right a bit and paint the next few square inches, and so on. He calls this Incremental because the Mona Lisa is appearing in increments.

Jeff suggests that a better approach is to take a blank canvas, sketch a woman and a background with lines only. Show that to the customer and get feedback. Next add some colour but don’t worry about the details. If the customer likes what you are creating keep going. Each time you increase the fidelity of the picture. This is what Jeff calls Iterative.

In Jeff’s language feedback occurs on each Iteration. In my language feedback occurs with each Increment.

You see the confusion?

I’ve tried applying Jeff’s language to my model, I’ve mentally tried to say “OK Jeff, you are right, I’ll change” but the words don’t work for me.

The thing is, and this isn’t always obvious: Jeff and I are discussing different problems.

His context, the problem Jeff is addressing is new product development where the customer doesn’t know what they want.

My context, the problem I am addressing here is: Teams trying to be Agile within an existing organization.

I use the words Iterative, Incremental and Evolutionary to describe the different approaches to implementing Agile within organizations. I try desperately not to say one is better than the other (although I fail miserably usually). Armed with this language I can describe what I see in companies, in teams, and I can advise accordingly.

I have no problem what so ever with Jeff’s use of the words in his context. In fact I agree, if you are doing new product development it may well make sense to increase you fidelity each time round the loop.

Which leads to the interesting question: Could you combine the two models?

Lets consider the four cases:

1. Jeff Incremental, Allan Iterative: This would be a team trying to perfect a small part of system from the requirements document before moving on to the next with little or no feedback. In other words, pretty much what most companies who have 100% faith in the requirements document try and do and fail badly at.
2. Jeff Iterative, Allan Iterative: This couldn’t exist, in Jeff’s model Iteration allows for feedback while in my model Iterations are devoid of feedback.
3. Jeff Incremental, Allan Incremental: This is case #1 but with added feedback, this would be problematic; A recipe for technical debt and an inconsistent UI. The team would complete one section to perfection, feedback would cause the next section to be a bit different, it would be perfect when it was complete but it would be inconsistent with the first part. As you progress across the Mona Lisa the style would change. It would be like having Leonardo De Vinci paint the picture over the course of his career. The final parts would be very different to the first.
4. Jeff Iterative, Allan Incremental: This could work, it could be good. The team would be producing low fidelity versions which are deployed to live as they go along and feedback is incorporated. The only problem here is that the requirements document (upon which governance is based) would rapidly become out of date, there would be tension. If you reformed governance then you’d probably be at the model I call Evolutionary.

So there you go.

In a nutshell: we use the same language to address different problems and in different context.

Sorry, the world is complicated.