Blog: Defining Requirements in Hybrid Projects
In this article, I gather my thoughts on defining requirements in hybrid projects that apply traditional project management combined with agile development methods. Today, such a model is a very common way of implementing software in, for example, large Finnish companies.
The dilemma of the hybrid project
The progress of a traditional project is typically tied to some control points, quality gates, etc. One critical gate is where the project is allocated funding and other resources for the actual development phase. The traditional model at this stage would have completed the requirements of that phase and could be used to assess the workload and commitment to the objectives of the phase.
In the agile model, on the other hand, such a broader commitment is not made, but one sprint - usually two weeks - is planned at a time. Requirements in the backlog can be refined, added, or removed during the sprints as needs and implementation boundary conditions become more precise. Agile practices include describing requirements in the form of user stories. For example:
As a customer, I want to be able to enter my address in my profile information, so that I can get deliveries to the right address.
The challenge is easily a "moving target". The high-level goals required for project management have had to be defined without precise requirements. In high-risk projects, these goals are likely to change a lot during the project as agile implementation produces new prototype releases and understanding of how they work increases. The end result may be great, but it doesn't meet the original goals. The project steering group is at least embarrassed and the traffic light controls are yellow or red.
How can this dilemma be alleviated?
The requirements of hybrid projects should not be based solely on user stories. Many variations of agile designs make it possible to compile stories related to a particular functionality into features and / or epics. It makes sense to use these same elements of definition to describe the objectives of the project as well. However, simply naming features does not solve the issue. They must include enough detail to know at least:
- feature acceptance criteria and workload (rough level)
- dependencies on other projects
- implementation risks (e.g. new platforms or technologies)
In a hybrid project, therefore, it is usually not advisable to start the implementation with the development team at the outset. Instead, the features for the next development phase should first be defined at a sufficient level to cover the needs of project management. Once the quality gate has been reached and the dependencies and risks have been mapped, the planning of sprints will be easier in the future.
A project testing organisation is also usually happy if they have clear feature-level requirements at their disposal when the development phase begins.
Then we have the NFRs
Non-functional Requirements, in agile or hybrid projects, may come to the team's attention unexpectedly. As the name implies, these usually do not appear when user stories are written down with users. Non-functional requirements usually relate to one of the following areas:
- Performance
- Security
- Usability
- Accessibility
- Brand compliance
The project should therefore have an agreed procedure for compiling and addressing these with the necessary stakeholders. Typically, the organisation's legal, information security, and information management departments, among others, define their own non-functional requirements for new projects or products. If these are ignored at the beginning of the project, then the cost of adding them afterwards can be significantly higher.
As a result of processing non-functional requirements, technical "Enabler stories" corresponding to user stories are created for the project backlog. If necessary, also complete technical features can be added. Bearing in mind the hybrid dilemma mentioned above, these should be included in the initial feature design.