What is agile? If I summarize my point of view these days, it’s a culture of evolution in a complex environment. In this complex context, agile proposes pragmatic responses: an often iterative approach that concludes its cycles with “finished” states (otherwise iterative doesn’t make enough sense). To this we must add a very important, fundamental notion, which comes largely from one of its ideological fathers, lean: value, the why we do things. The often iterative approach is therefore prioritized by this value. We do things iteratively, they are prioritized by value, with a finished state at the end of the cycle (it’s fundamental I remind you). Well here are some foundations laid, far from complete but which will support my little debate.

But what is this value?

In the often competitive context in which I operate, that of a market in competition, I summarize it into 3 major families. Generally we find this value by questioning the why. So usually I propose as an example 3 major families (non-exhaustive):

• cash, money, that what we do brings in: if I deliver such functionality I could earn $$$. It’s good because the measure is very effective.
• image, communication: if I deliver this functionality I will make myself visible, I will take position in such and such market, I will fill a competitive deficit, etc.
• a performance: it’s the first time that this service/functionality is delivered in this form, it’s the first time that we can so quickly do…, it’s the first time that we can aggregate these different types of data, etc.

You may have other sources of value, these are only very common examples, the main ones in my eyes, in my context. One could envision NGOs whose value is to: distribute as quickly as possible their stocks, allow access to certain medications to a greater number, etc. As I told you my list is not exhaustive. But even my two previous examples still fall into my third family: performance.

A User Story must express value

It is therefore essential. essenTIAL. ESSENTIAL that user stories (the most common formalism for expressing needs in agility) express this value. We generally say: “…so that [put here the value that the user story should generate]”. However, and this is where I come back to the subject of this post, what is a technical user story? It’s an admission of failure because it’s a user story without value. Open the floodgates to incandescent flames: technique for technique’s sake has never had value. So a technical user story has no value.

But Pablo you haven’t really told us what a technical user story is. Oh sorry. A technical user story is an expression of need that covers a technical need: we must deploy such type of technical component, we rewrite such technical functionality, we must replace such type of libraries. Two new bad reasons for technical user stories (the first being that they don’t possess value):

• We’ve fallen behind and we’re refactoring. It’s a shame, refactoring should be all the time. It happens to everyone to fall behind, me first, nevertheless, it’s a shame.
• We estimate that the technical piece to be done is too big to be integrated within the realization of a real user story, a user story with value, a business user story.

The right agile way to handle technique

Technique is the means, it’s the how. It’s not the why. It’s not the value.

These technical aspects must be handled under the cover of handling a business need, which itself has real value. As such client, I wish to be able to blablabla so that I have such or such value. The response, the how, brought to this request potentially implements strong technical aspects: use of such and such components, etc. Technique is very present, it is very important (did you doubt it?), but it is the means, the servant, Guinevere’s Lancelot, the Queen’s d’Artagnan. I’ll come back to this.

Too often teams estimate that the technical part is too big to be hidden under a business request. It’s generally, from my observations, a lack of training, a lack of habit, and especially a lack of appropriateness and acquired knowledge concerning the often iterative approach of agility. I never get any interesting justification concerning a technical user story. It’s, I think I remember: always until now, an admission of failure (in the sense that it diverts us from agile culture).

Small clarification: having screens that display quickly, being able to be broadcast on exotic terminals, etc is not technique, these are indeed business points: I need to see my curve update in real time so that…, I wish to be able to consult this information on… so that…. I come back again to the two “NGO” examples used above: distribute faster, access more people, this is not technical, it’s business.

Is it serious doctor?

It’s an admission of failure, it’s a shame, it tickles us, scratches us, but it’s not a drama. It happens, to the best as well as to others. It’s a shame because we lose sight of an essential strength of agile: deliver in an often iterative way finished value (and prioritized by value).

Agile is in my eyes: business focus. When an NGO wants to distribute more bags of rice faster to a more varied population, it’s their Business. It’s their trade. And my role as an agilist is to unblock, to better activate, these sources of value. In English to be in (like scrum or extreme programming): it’s business focus agile, value enabler.

However can we systematically avoid technical user stories? We should, but it depends on contexts (bingo). In any case it should tickle you, scratch you, bother you around the edges, put big, bold, flashy warnings. Otherwise in my eyes you lose the meaning of agile.

The technical User Story is dead, long live technique!

Technical profiles too often take this as a full-scale attack, a denigration, wrongly. In fact, those I meet quickly learn that all this quickly turns to their advantage as well. To each their own turf. By becoming the Servant of business, means/how of the why, technique gains its freedom to exercise its art as it sees fit. It doesn’t mean it no longer has time to do technique, on the contrary, it means it manages exactly as it wishes (and hopefully intelligently, effectively, with agility) the time it devotes to respond technically in the best way to this value creation which is the ultimate goal of the user story.

Finally there is grandeur in being the Servant, and in agile culture it’s an art.

Feedback!

Florian, yes I consider that “refactoring” (as you describe it) is technique for technique’s sake. But it’s in no way devaluing or useless as you seem to imply from my mouth. This is in no way the case, it’s very important to “refactor”. But this value, this usefulness, this “power” I would even say should not be the subject of our realizations. It’s the indubitable way to do things well, but not the target. It will bring value as you say, but it’s not this value to which I’m alluding, and it’s not this value that should lead the actions, projects, agile products. For me it will bring efficiency, ease, performance, but not value in the business sense.

Yes from my point of view it’s waiting for the business story in question that allows launching this refactoring project, it’s in any case the best solution in my eyes.

Philippe & Claude: we don’t agree. Very well! It’s your strictest right. But I don’t agree with your analysis. You’re making a catalog of types of User Stories, a nomenclature, of things that we encounter. Yes. No problem. But from my point of view it doesn’t change the fact that everything that distances us from a user story with real value (that of the product owner, of stakeholders) is an admission of failure. I’m not going to re-explain myself, just reread my point of view above, I absolutely don’t deny the crucial importance of technical aspects, but I consider that doing anything other than user stories with value for product owners and stakeholders is a deviation that distances us from our objectives and our agile culture. And the spike you mention Claude is all the more a deviation as it doesn’t provide us anything “finished”. So, there as well, like technical user stories, it’s a stopgap (sometimes necessary unfortunately).

Fabrice has just proposed a nice formula.