Skip Ribbon Commands
Skip to main content

Fast Digitalization of New Regulations

With NNIT’s agile work process ‘From law to backlog’, public organizations and private companies can quickly and efficiently adapt their digital systems to comply with new laws, rules, or organizational changes.

By Jacob Trier

It is rarely a simple matter to convert a new reform from legal text to digital code. Public organizations and private companies often find themselves spending a lot of time updat- ing their digital systems to support new rules or changes of existing practices. Therefore, NNIT has developed an agile work method that reduces the development process and increases the quality of the final solution.

“We call this method ‘From law to backlog’.  It is applied in the phase just before the agile development process where business require- ments are converted into specifications. This method provides us with a quick and accurate overview, which is necessary in order to convert the client’s needs into specific code. In one particular case where we developed a self-service solution, we reduced the time spent preparing an application for develop- ment by 50%,” Vice President of NNIT, Lars Andersen, explains.

Epics and Wireframes Get Fortified

The basis of the ‘From law to backlog’ method is a close collaborative partnership between the business manager and the development team. In a series of meetings, the overall task will be split into individual sentences describ- ing the system requirements. This could be ‘Automatic cancellation of benefits when exceeding time-limits’, for example. These descriptions are called ‘epics’ and serve to ensure a common understanding of the commercial goals. At the same time, the user-friendliness consultants (UX consultants) prepare early drafts of how this can be repre- sented as displays. This also serves to ensure the necessary transparency in relation to the processes required to get the different system components to perform the task correctly.

"At the commercial level, it is often relatively simple to understand the process. In practice, it can be implemented in different ways depending on how you wish to communicate with the users. Should the communication be sent as a letter, an email, a text message, or should a case worker be instructed to contact the citizen by telephone, for example? Furthermore, it may be a complex task  system-wise, as many systems have to be changed and data have to be updated at multiple levels,” Lars Andersen says.

How the Process Works

When the individual epic is in place, the development work is performed as a circular process:

  1. The business manager will present a  specific business requirement in the form  of an epic.
  2. The business architect of the development team will look into the systems and services that are required to come up with a solution and describes the different scenarios that the users may experience when they use the system. At the same time, the team’s UX consultants will prepare the first drafts of the user interface.
  3. Different types of users and stakeholders are involved to qualify the scenarios and  user stories that form the basis of the  development work.
  4. Taking the user involvement into account, the wording of the tasks will be revised to reflect the experience and new ideas result- ing from this involvement. Subsequently,  it will be concluded as to whether this epic is ready to be included in a backlog or whether it requires an extra look.

This work method ensures a well-defined and recurring process where the needs are con- stantly challenged, new ideas arise, and the transfer of knowledge is reduced. There is a strong focus on continuous learning and cooperation. For instance, we use visual methods to ensure that the expectations for the final product are adapted, so that all of the stakeholders will be involved at an early stage and retracing will be minimized. In the process mentioned above, the user involve- ment implied that we integrated a ‘stop button’ in the system where the users have the option to override the automatic pro- cesses. These creative ideas never arise from the conventional performance specification processes,” Lars Andersen explains.

Quick Operational Readiness

A central principle of the ‘From law to back- log’ method is that efforts are made to ensure the fast delivery of an operational solution that only includes the functionality that is absolutely necessary – the so-called ‘Minimum Viable Product’.

“This principle ensures that we avoid the classic situation where the launch of the system is postponed all the time because it takes longer than estimated to comply with all the requirements - the original requirements as well as the new ones emerging during the process. The solution should not necessarily be launched right away, but it ensures that the client has a ready solution at all times. This provides some leeway to consider when the priority of launching the solution exceeds the need for new functions,” Lars Andersen says.







NNIT here+45 7024 ​ ​​​​​​​​​​​​ here



Testing IT Systems for the Public Sector Requires Special Skills IT Systems for the Public Sector Requires Special Skills
Testing Security in Applications and Data Security in Applications and Data
Testing Is Essential in the Enterprise Sector Is Essential in the Enterprise Sector
Take Advantage of Automated Test Advantage of Automated Test
Testing adds value to Structured IT Changes adds value to Structured IT Changes
Good Requirements Are Key to Good Systems Requirements Are Key to Good Systems
Risk-based Testing Is a Good Investment Testing Is a Good Investment
Static Test – Your Best IT Investment–-Your-Best-IT-Investment.aspxStatic Test – Your Best IT Investment
Testing Based on Specifications Based on Specifications