Agile Specifications

Through my work as a troubleshooter in the last ten years I was able to save a great number of development projects: For each individual project, I started by rebuilding the team and reassessing the workloads for the system to be developed, a strategy that made sense given the fact that I needed clarity about requirements in my negotiations with the stakeholders. The goal was always to bring the respective project back on the right track within six months.

There was one thing all of the projects had in common; either there was no specification (at least none worth mentioning) or there were piles of documents impossible to digest in any way humanly possible. In other words, I either had nothing or way too much to go on. Thus, prospects were not too good.

In addition, engineers are not too keen on signing specifications. Very often you have to chase the decision makers to try and get clearance, in many cases resulting in even more requirements instead of the desired clearance. What I needed was another approach, a way to create a specification including clearance within just two weeks.

What is a specification and what does not belong in it?

A specification is a kind of make-a-wish for customers. It includes of technical requirements for a system to be developed. There are two types of requirements, project requirements and system requirements.

Project requirements are requirements that are relevant during a project but turn irrelevant as soon as the project is completed, e.g. budget, milestones, capacities etc.

System requirements, on the other hand, are requirements that persist even after completion of the project.

In other words, project requirements for that project I did 10 years ago are of no interest to me but the (technical) system is still used by my clients. The specification includes the technical requirements for a system, the project requirements belong in the project manual.

Specifications are not target specifications!

A target specification serves a completely different purpose than specifications; it is the response to a specification. In a target specification I clarify the requirements from the specification; I can reject, accept or detail them. In agile environments target specifications may also be called user stories or epics.

These two types of specifications must not be confused with another; the customer is responsible for the specification (i.e. the marketing or product management) whereas the target specification is the response by the development project.

Mixing these two up creates two problems: Firstly, I lose the ability to differentiate between desired requirements and those that are to be developed. Secondly, very often the two separate documents are essential ingredients of legal agreements.

From zero to clearance in two weeks

As a systems engineer creating a specification I usually need between two and six months to finish my task. To be able to do the same in just two weeks I need a completely different, more pragmatic approach. I found a way to create a specification in two weeks, five steps and with the help of two basic rules.

• Step 1: Elicitation

A kick-off meeting is the perfect way to collaboratively define and visualize what the system is and what it must do. We then use check lists to record what documents and other information exist.

• Step 2: Structuring the content

I then screen all the information available, evaluate what is meaningful and complete the template I use for specifications. I refine the results and verify the requirements as well as the grammar.

• Step 3: Closing gaps

I close the gaps made apparent in Step 2 by eliciting, evaluating and refining additional requirements.

• Step 4: Verifying and reflecting the result

The next step is a peer-review process. I hand the document over to experts who assess and comment on it. In many cases this leads to addendums and additional information I use to create new intermediate results. The nice thing about this phase is that all participants get to know the document and at this point have all commented on it. Thus, close to everything has been clarified, which is an essential part of my strategy.

• Step 5: Creating the final version

This final version is worked through in a moderated review workshop by the project team and me. A review protocol is used to record all things that stood out to us as well as recommendations for the changes planned. After all changes from the review protocol have been transferred the release as well as the clearance is effected automatically.

We now have a specification and a review protocol containing all peculiarities. Since all participants have contributed to these documents no further signatures are necessary for the release.

The two rules

Being able to use these five steps to reach my goal in two weeks requires two rules that need to communicated very clearly:

1. Whoever is present is present. Whoever is not present approves.This rule helps to avoid that the specification is crippled after the workshops. Additional change requests or requirements may be considered, but only for the next release.
2. No feedback means approval.If I ask for feedback , e.g. for peer review versions, and get none in the agreed time frame this is regarded as approval. Again, belated responses may be considered for the next release.

Clear steps. Clear rules. High pace.

This way all participants can decide for themselves how important the specification is to them. In practice this actually works like a charm; there even have been clients that obtained ISO 9000 certification at the same time they delivered valuable content.

Can specifications be agile?

Time and again people are asking me whether specifications can be agile. The answer is simple.

Specifications are essential to development projects. As a systems engineer I can compile them the traditional way or, since the word software can easily be replaced by the term specification, by applying an agile approach.

This way I can utilize specifications in agile environments; by creating the first version, realizing it by applying Scrum or similar process models and creating the next version based on an important milestone, a version that incorporates the newly acquired insights.

Specifications do not need to be static. They describe the current state of wishes and requirements for a system; nothing more, nothing less.

Conclusion

A specification created in two weeks will not possess the same level of maturity as one created in the traditional two to six months. This is no problem because it is not the goal; the idea behind agile specifications is a more pragmatic, hands-on approach. Simply put, I want to be able to initiate the implementation based on an accurate and approved specification. 

Applying them in agile environments is also possible since I can create multiple versions of a period of time, making them blend in perfectly with agile projects.

You may like this too:

Project Launch – Why is it so difficult?