Specifications in the agile world

Guest contribution by | 28.09.2020 | Project management | 0 comments

Customer and requirement specifications originate from classic project management, but are also indispensable in agile projects – because they help the client and service provider to achieve a common goal.

Agile projects? Are a great thing, most people can agree on that nowadays. But when “agile” turns into “wild and chaotic”, when nobody knows what the goal actually is or everyone is pursuing a different one, then it becomes clear that, despite all the flexibility, the customer and requirement specifications, these supposedly bourgeois helpers from classic project management times, still create the basis for trusting cooperation today. They are still the “safety net” for both sides, providing clarity and structure: Are they all pursuing the same goal? And how?

Some customers perceive them as an antipole to the popular agility. They fear that this leaves no room for the unforeseen. Or, without ever having seen a partial result, they may have to commit themselves in a kind of blind oath of loyalty. The solution that combines plannability and spontaneous adjustments, the best of both worlds, so to speak, is: flexible requirements management. Others also call it a backlog – the requirements that have to be processed in the project, but which can be dynamically adapted. I still call it customer specification, because in my experience, customers are more likely to understand this term. And because, in my opinion, it also shows in terms of language: In agile times there are also budget and time frames, and I appreciate that. Fixed requirements help to meet them – “just get started” on the basis of verbal agreements with supposedly clarified goals can backfire.

Flexible requirements management: the best of the classic and agile world

The ” classical” procedure with

  • order clarification,
  • project planning,
  • implementation and
  • closure

stays the same at first. However, the cooperation with the customer becomes closer and continues throughout the entire project period. The specification is not fixed after its creation. Instead, the project team develops the later end product from initially defined key features in an agile manner. This works best by collaborating in digital PM tools – in which, unlike in the past, the customer and requirement specifications may not always be clearly separated.

We use agile, flexible requirements management, especially for innovative products: In one of our current technology projects, for example, the customer’s team is working on the technical concept of their product. We remain flexible by incorporating new requirements into the customer specification in weekly coordination. This creates a commitment that does a project good. Because no one can “go underground” for long; all those involved always know the current project status and above all: the overall objective.

In our agile everyday work, some points have emerged which I would like to share as tips for other project teams:

#1 Not too little, not too much: the specification as a common basis

In our projects, it has proven to be a good idea to work out the specification together – the customer contributes his industry knowledge and his wishes, we contribute our technology knowledge and solution competence. The joint preparation, in which we analyse the wishes, is quicker than a ping-pong of the concept.

In this analysis we jointly specify all requirements – technical, functional and visual – as far as they are visible. At the same time, however, only as far as both the customer and the developer understand them. Both sides must know one hundred percent why a requirement exists and what it looks like. User stories and the question: WHO should do WHAT – and WITH WHAT benefit? It helps customers and developers alike to always plan requirements from the user’s perspective.

#2 The customer wants, the developer solves: Why only the service provider has obligations

We initially describe the respective objective of the requirement in the specifications – and not the solution. As a service provider, we are better able to develop or select such solutions. Although the customer knows his company extremely well, he may not know all the technical possibilities and thus, in case of doubt, not the best way to reach his goal.

Nevertheless, customers often have the feeling at the beginning that they have to “bring along” the solution themselves – a good project manager must be able to relieve customers of this perceived “solution obligation”. For example, if a customer believes that his website needs a green button, we first ask: What should this button do? What problem should it solve? And why does the customer think the button should be green?

#3 Connect digital tools: Agile requirements management with Jira and Confluence

We work with the project management tools Jira and Confluence in combination, and the customer and requirements specifications are sometimes seamlessly integrated. We use the tools to document and organise solutions and project stages. You don’t have to reinvent the wheel for this: The classic work breakdown structure proves its worth and helps to keep an overview even in projects with numerous requirements. Thanks to the tools, requirements management is also audit-proof.

We give customers full access to joint projects within the tools. This transparency is also a confidence-building measure, because we offer them the greatest possible insight and constant access to the current project status. As a rule, those responsible on the customer side can work well and safely with the tools from the outset.

#4 Changing direction allowed: buffer for change requests

During the initial analysis, we explicitly define with the customer how we will deal with change requests during the course of the project. This means: if necessary, we consider a buffer budget in advance. We use it if coordination and review of the project roadmap reveal changes that deviate from the originally defined requirements. It guarantees that in such cases we do not have to go through a new quote and approval process – and the project remains truly agile.

Conclusion

The methodology in project management must always fit the project. But the best possible planning reliability is good for all those involved. Even in agile times, I have never seen a customer who, when working together with external service providers, aims for a project blind flight according to the motto “Let’s just get started”. Completely agile work can work safely in projects such as internal product development. However, I believe that defining requirements always makes sense in order not to waste money or time.

That is why we rely on the “hybrid process” described here, which consists of specifications and agile working: At the start of the project we draw up the initial specifications with rough calculations, but these can grow and change dynamically. For this, the above-mentioned budget and time buffer for change requests is essential. In this way we combine the classic and agile world and work on projects in a goal-oriented, resource-friendly and dynamic manner.

 

Notes:

Do you want to see a visually impressive German website? Then just have a look at 3m5.de. It is worth a visit!

Further details on specifications, scenarios of creation, content and structure and typical errors can be found here »

Philipp Menzel

Philipp Menzel

As a former web developer and team leader, Philipp Menzel knows project requirements from many different angles. At the Dresden-based IT company 3m5. he is now responsible as project manager for agile projects for major brands, viewing the people and companies involved as the linchpin.