Specifications are loved in the classical management world because, in principle, every single nuanced step and action is written down in advance. We organize the content hierarchically, and then rightly think that once a developer gets it, all they have to do is go through the specification step by step, and we magically get the wonderful, flawless finished product.
This may even be true in a manufacturing environment. But certainly not in a knowledge-based economy, in a software development environment. Despite the global automation specification, there are still many uncertainties in software development. In the process of any development, new information regularly comes into our possession that can overturn the original specification.
In the world of software development, both technologies and languages are changing and evolving at an astonishing speed. The same volatility is true for business needs. A well thought-out operation or model can lose its meaning or value after two or three months.
This is why specification writing carries the risk of unnecessary work. In a specification-driven collaboration, no stakeholder is eager to indicate in the heavy documentation the information and changes that inevitably occur over the time scale of a software development project. So everyone has an interest in avoiding this, which certainly does not support close cooperation based on common interests.
So when is it worth writing a specification? For a small project, you can write a small specification to meet small needs.
But what should you use instead of a specification?
Our related blog article writes about the five levels of Agile planning, but for now our answer is the Backlog.
A Backlog always consists of well-defined development units, which are prioritized in relation to each other.
The high-priority elements of the backlog are continuously refined, while later elements are not detailed until a business decision is made that they are next to be released to the market.
Learn with us! Be a Product Owner!
It is worth creating a backlog instead of a specification
A backlog is a special artifact that has some important and unique characteristics. These are fixed features. In return, it allows an amazing amount of flexibility, unlike a classical specification, where both parties have an interest in inflexible implementation. A typical specification-driven dialogue:
- “I have planned it precisely!”
- “And I’m not willing to pay for anything else!”
- “It was never part of it!”
- “I think it is default, and it clearly has to be included!”
Backlog’s permissive flexibility relieves the client and the service provider from having to shove conflicting interests down each other’s throats.
How does it achieve this flexibility?
The smallest comprehensible unit of the Backlog is the so-called User Story. The User Story also follows some basic genre rules (more on this in a later post), and if we write User Stories following these genre rules, the Backlog will be able to connect development and business in a way that no other documentation ever can.
User Stories describe a feature through the eyes of the end user, and developers break it down into estimable, well-defined tasks accordingly.
From a business aspect, User Stories are the smallest interpretable unit, which explain how the software works and are understandable to everyone, developer’s subtasks on the other hand are not.
The set of developer’s subtasks of a User Story practically covers our needs towards an excellent specification. In fact, it goes much further than that, because it also includes general constraints and quality assurance elements for each User Story, as opposed to specifications, where these are very difficult to adhere to and follow.
Practically, developers can start working from the moment you have some User Stories. Especially if the User Stories have already been prioritized in some way.
Priority and importance can always be established between two items. I understand that everything is important and everything has to be done, but there are always more important tasks, and there are tasks that have to be done before everything else.
So the most important feature of the Backlog is that it consists of prioritized User Stories.
I also admit that it is not always worth writing a User Story. For example, there are technical tasks that cannot be attached to end-user processes. They will be defined and prioritized as separate Backlog items.
Backlog prioritization is not affected by whether it is a User Story or another backlog item. The key is for everyone involved to be aware, in all circumstances, of what needs to be worked on, what the next task will be, and what should not be started yet.
This can only be done with the Backlog, if we follow its rules.
What does the Backlog give us?
One of the gifts of adhering to Backlog priorities is that developers will not surprise management. Management will always know what they are doing, why they are doing it, and developers will never get lost.
Let me point out again: populating the Backlog is not an arbitrary action. Each and every element of the five levels of Agile planning must be strictly adhered to, or our efforts will fall into chaos.
Once we have our backlog items ready, prioritized according to some criteria, then all we have to do is get the developers to write the subtasks in order of priority… and complete them.
Estimates of subtasks must always be given in the unit of measurement as indicated in the contract!
In addition to continuous prioritization, we also need to ensure that our estimates are sufficiently predictable. It seems like a contradictory demand, since we cannot plan every single step of every single Backlog item in advance. In fact, most of them are not even really explained.
Still, there is a legitimate need to come up with some kind of an estimate.
The answer lies in the Backlog’s relative predictability.
The Backlog also helps to extrapolate the expected completion time and resource requirements of unplanned items.
With some routine, we can write backlog items whose complexity can be determined in relation to each other. Compared to an arbitrarily chosen Backlog item that I take as the base, I can judge all the others as being about the same, twice as big, half as big, etc.
It is not a precise estimate, but that’s not the aim. The aim is to find out within moments, through a cheap and very quick check of the backlog items, if a target can be clearly hit, or if it is obvious from a distance that there will be trouble.
States other than the two obvious cases can be clarified in further planning.
With relative estimation, management can be informed about the state of the Backlog and the expected arrival of prioritized items without having to invest unnecessary effort in planning, much of which is likely to end up in the trash (changing business environment, technology rules and regulations, user or customer needs).
The colleagues who oversee and manage the Backlog are constantly challenged, iteration after iteration, to go through the remaining elements of the Backlog with new information, to check and, if necessary, to adjust priorities and constantly refine estimates in terms of expected delivery date and/or resource requirements.
In a well-run Agile project, the time spent on planning is between 25-45%, based on measurements over the last 10 years and my personal experience.
A Backlog allows:
- the five levels of planning required by the methodology
- the breaking down of the output elements corresponding to the five levels according to a predefined approach
- (even requires) continuous prioritization
- flexible and quick response to changes in the market and/or technological environment through continuous prioritization
- the recognition and objective justification of “go” or “no go” decision situations