Those who don’t know well Agile management methods can feel that the team is working without any specifications. Goals vary from one sprint to another; we don’t know exactly what’s going to be in the next sprint… It is although far from the truth. Stating that an Agile project doesn’t have any specifications is completely wrong. However, what is true is that the way Agile functional specifications have been designed is entirely different from a traditional method.
Small reminder on functional specifications
Functional specifications aim to precisely detail all the functions of a software or an application, to then establish the functional scope of the project.
The drafting of the specifications is based on the needs expressed by the client, which are generally regrouped and reformulated in a specification note. The specification of a function is therefore going to thoroughly detail the services it’s going to provide to the application or the user. The display of the home page, of the menus, the users’ identifications and the management of the shopping basket, if it’s an e-commerce website, are all examples of what can be featured on a website.
Functional specifications will thus detail the business aspects of the application as well as their implementation and set up.
At this stage, technical solutions are not tackled. This means that the different functions of the application will be detailed, but not the resources to carry them out. The structure, technologies and the materials will be detailed in the technical specifications.
An aspect sometimes forgotten about technical specification is that they need to feature testing scenarios. It is indeed important at this stage to plan how it will be possible to check that the developed function meets the outlined functionality.
Drafting of the specifications within a traditional project management
As part of a cascade model or V-model project management, the functional scope is perfectly centered from the beginning. This means that we set up an exhaustive list of the functionalities before detailing them one by one.
Each functionality will be detailed to make it understandable by not only the client, who will be able to assess that the description effectively fits what he was looking for, but also by the development team, who will be able to create an accurate version.
With a traditional project management method, the development stage can only begin once the entirety of the functional specifications have been drafted and validated by the client. This means weeks, even months, can pass between the drafting of the functional specifications and the start of the developments.
This method is therefore suited for projects of which we know the functionalities well, the heart of the profession, and that will not vary, or not a lot, over time.
This drafting process of the functional specifications that has to be completed before starting the development phase is nevertheless a bit problematic.
To begin with, users are rarely able to comprehensively detail the entirety of the functionalities they want to be featured in the application. Moreover, as the process lingers over time, it is very likely that the needs’ assessment, the drafting of the specification note, the drafting of the functional specifications, the developments and the tests will be carried out by different persons. Communication will thus be important between all the contributors in order to not lose any information. Transmitting this information then becomes even more complicated with lengthy projects because people often come and go without ever crossing paths.
The upkeep of the functional specifications also has to be assessed. Even if needs may vary throughout the project (if not, better opt for an agile method), specifications have to be regularly updated to reflect breakthroughs and potential problems identified throughout development.
Agile functional specifications
As we’ve just explained, it is very complicated, even unrealistic, to be capable of drafting comprehensive functional specifications.
Can we then start developing without relying on specifications?
Of course not. Project management leaves no place (or very little) to improvisation. We thus need functional specifications to convert the client’s task functions needs and then guide the technical teams within their developments.
Agile functional specifications will therefore not be drafted at the beginning of the project. They will be shaped throughout its development. Each functional specification will be drafted right before its development. For the process to be efficient, precision and thorough communication will be vital between the product owner on one side, and the development team on the other.
Opposed to a traditional method, the responsibility of drafting the functional specifications is shared. The client, through his product owner, will help to describe his needs and the specifications. The development team will define the structure and the technical solutions which have to be applied. The identification of tests, tailored to the developments, will allow to, on one hand, refine the specifications and, on the other hand, assess faster the conformity of the application’s behavior.
Following this procedure holds several advantages.
The project unfolding as iterations, the Agile functional specifications become profitable as soon as they are drafted, for the entirety of the project’s period. From this precise moment, you have to your disposition all the information gathered since the beginning of the project, including new restrictions that may have arisen during previous sprints. Furthermore, the Agile functional specifications having been drafted right before the developments, the development team still has them in mind upon realization. This is much easier than having to go back to a document drafted weeks before, time at which the project might not had been incorporated. Developers will then be more efficient because they won’t have to go look for information from previous editors.
Developments and Agile functional specifications alike are centralized. An Agile functional specification focuses on only one function of the application, often displayed as a user story. This is ideal to better focus on the given functionality, by disregarding information interfering with the understanding of the need.
Nevertheless, Agile functional specifications require working with just-in-time methods. It is then especially risky to draft specifications according to developments to be carried out during the ongoing sprint. It is important to anticipate and to create the functional specifications in parallel, before starting the development’s sprint. If you have functional specifications in hand when breaking down the user stories and during their subsequent distribution in different tasks, estimating the sprint’s realisation workload will widely be easier and therefore more precise.
Wrapping up Agile functional specifications
Agile functional specifications operate projects through a different modus operandi. They provide flexibility (they can be adapted), precision (focusing on a centralized functionality) and reliability (taking advantage of the project’s history and recent information). They although require great precision so that their preparation alongside the sprints will ease the developers’ task.
Feel free to start a free 14 days trial of the complete Agile project management solution by Nutcache, which puts at your teams’ disposal a complete package of tools to manage your functional specifications.
