4

I work on a team that manages DevOps tools for a software company. When an engineer from one of our product teams wants to use one of our tools, they clone a series of Jira tickets and work through them in order. This could be something like:

  1. Create an account at externalservice.com
  2. Reach out to us when your account is set up
  3. Start using the service; here are some examples of what you can do

We call these onboarding flows "non-functional requirements", and I just found out that's an Agile concept. Reading about NFRs, it sounds like they typically describe the standards a product has to meet around performance, security, and usability, e.g. "systems should be online 99.9% of the time".

My question is: is an onboarding workflow related to a product an NFR in Agile, or is there another concept that fits better?

5

TL;DR: No. Onboarding is a waste.


Time and effort invested "Onboarding" is neither a functional or a non-functional requirement. In our project, we had failed to find how to address such situations within normal agile frameworks, and even on the agile manifesto itself. We went deeper and found a potential answer for such situations in agile's parent - Lean. More specifically, in Lean waste management.

In our teams we started tracking efforts invested on such wasteful activities. Onboarding is a wasteful (albeit necessary) activity. The benefit of tracking this as a waste is that it brings attention to how much effort is repeatedly wasted and helps identifying opportunities for waste reduction and thus, increase profitability.

With that in mind, teams should strive to have low context environments (or applications, or code). The better and clear the environment, the lower the context and thus, shorter the onboarding.

3

Non-functional requirements aren't an Agile concept - they very much pre-date agility. Non-functional requirements are about any of the criteria that don't relate to specific behaviors of the system under design.

I don't think that an onboarding flow would be a non-functional requirement, but the attributes including usability, supportability, and availability may be related to some of the steps that you identified. Usability is related to how easy or difficult it is for the user to create their account and then start using the service. Supportability often includes any help-desk activities around supporting the user. Availability is about making sure that the user is able to use the system when they need or want to.

I don't think that an onboarding workflow relates to the product. It's closer to the business process. The functional and non-functional requirements of the product can put constraints on the design and implementation of the product to support the needs of the stakeholders.

1

Onboarding is an opportunity, when done right.

It's all about the goals, if the only goal of the onboarding is to have another productive member of the team, all the onboarding tasks will be a dreading wasteful time.

On the other hand, onboarding a new team member creates the opportunity to distribute knowledge, test current team's assumptions and ways of working.

Let me try to give some examples:

Your team owns 4 microservices, 2 engineers have worked intensely on those 2 while the rest of the team relies on their knowledge about them, when onboarding a new engineer is the perfect time to ask the ones with more knowledge to build a presentation or a knowledge sharing session for the new joiner, the rest of the team can benefit from it.

In many occasions, when explaining our way of working to a new joiner, they'd ask "why" many times, and in those asks we'd know the things we might be doing just because of inertia, because someone else that's not even on the team anymore proposed, or stuff like that.

To make sure this is a fruitful time, the mindset has to be a learning mindset where the ultimate goal is to make the new joiner comfortable enough to be able to ask challenging questions and being his knowledge.

Every time a new joiner comes in, the team is a total different one, the onboarding is the ability to make the new team better than the previous one.

0

Doing some work and preparing some jira tickets for it has no relation to "non functional requirements".

A requirement is not the work to fulfill the requirement, independent if it is a functional or nonfunctional one.

In your case, the requirement is "want to be able to use tool xyz". To fulfill these requirement, you have to "add an account", "grant access to the tools", "enable server connectivity" or whatever.

To split functional from non functional requirements is often not very helpful. In your case, giving access to some tools, how you would define the requirement "availability of the tool > 98.5% of work time". Is that functional or not? But whatever you define it a functional one or a nonfunctional one, what will this decision change? You have to find out how you can fulfill the requirement, maybe by redundant setup, by high amount on service desk workers or whatever.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.