Software releases are seeped with dramatic tension. After slogging away over several development sprints, the agile team passes the beta test or completed software on for presentation. How will it be received? Will the team’s hard work end in tragedy, with glitches and malfunctions galore, or in rousing success, with an evening of hearty pats on the back and bubbly champagne?

It’s tempting to over-manage such a highly-anticipated event and to keep tabs on the agile team, monitoring its every step.

However, agile teams aren’t meant to be kept on a short leash. They’re at their best when working autonomously. And sticking to a rigid schedule isn’t the agile way. Rather, it’s to “adapt to change over following a plan.”

So how does a manager assure the client of a release date and a quality product when the development team itself needs to call most of the shots?

It is possible for management to oversee a successful release without encroaching on the agile methodology. Here are a few tips and tricks to pinning down a solid release date and checking all the boxes for an optimal presentation of completed software.

1. Write a Release Plan

The first principle in the Agile Manifesto states: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

A release, then, is central to the agile methodology, and ideally something that occurs frequently. A release isn’t the increment produced at the end of each iteration, but rather the culmination of several sprints, and it’s passed from the development team into another environment for review.

Whether it’s a final product, a piece of final product, or a beta of the final product, achieving a release is a real milestone.

Making a plan ensures the release is executed smoothly. A thorough release plan includes the overall goal, which ideally has been discussed amongst all stakeholders using the MoSCoW method to clarify high and low priority requirements.

These priorities allow the team to review the backlog and identify those stories that must be completed during the release, those that might be completed if time permits and those it can put to the side. A date is determined for the release as well.

A release generally lasts at least three sprints. Agile is about adapting to change, and so this date isn’t hard or fixed. But the plan keeps the team on track and focused on a shorter-term business objective.

2. Discuss, Then Commit to a Release Date

Have you ever set aside an hour to mow your lawn, and four hours later you were still at it? Maybe the mower needed gas or a new blade, plants needed pruning and weeds needed whacking.

Estimating a project before taking a hard look at everything it entails is almost always a long shot.

When managing an agile release, then, it’s prudent to pin down a release date only after everyone on the team has sat down to evaluate the work at hand. Grooming the backlog and playing planning poker helps to gauge just how much work the team is taking on.

Another strategy is to simplify the stories as much as possible. Breaking work down into small, singular tasks is like shining a black light over the project, making it easier to spot any problems areas and potential snafus.

Whenever possible, it’s good to have these conversations face-to-face. The Agile Manifesto states: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” So much communication is non-verbal, and in-person conversation allows for voice-inflection and tone to come across.

After it’s all been laid out and discussed, it’s time to find consensus using the fist of five. The plan only gets a “go” when the anticipated release date is met with jazz hands from everyone on the team.

3. Let the Team Find Solutions

Any manager with his or her eye on the bottom line wants to oversee a software project like a hawk. It’s tempting to determine all sorts of things, such as how many sprints it should take until release and how many tasks should fit into each sprint.

It’s hard, and probably feels a little nonsensical, to hand the reins over to the team to figure these things out on its own.

However, this actually makes a lot of business sense. From writing code to testing, the software team knows the ins and outs of the project better than anyone else. And so allowing it to plan and structure the project is the surest path for success.

But how can you trust you’re really putting the project into good hands? Another principle of Agile Manifesto states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

If you’ve hired a team of go-getters with plenty of domain knowledge, they’re fully capable of working on their own and getting the job done.

4. Manage Workflow, Not Work Hours

Keeping a release on course hinges in part on efficient processes. Ideally, a team works at a consistent velocity, completing a similar number of story points each iteration.

How does a manager or scrum master keep the team on an even keel?

One thing he or she shouldn’t do is hand everyone a lengthy to-do list and put them on treadmills running at a grueling speed. This isn’t a recipe for quality work, but simply a fast track to burnout.

The Agile Manifesto states that “Simplicity—the art of maximizing the amount of work not done—is essential.”

Creating a high-functioning agile team is really about smart practices. One such practice is limiting the number of stories a team works on at once. Having too many irons on the fire creates cognitive burden and scatters everyone’s focus. Work is sloppy and time is wasted.

Instead, working on only one or two stories at a time lightens the load and unleashes the team’s energy. The team swarms to bring each story over the finish line, then moves onto the next item in the product backlog.

A second efficient method is planning sprints and daily tasks at the latest possible moment. The agile method is to work in the present, reflect, then adjust the path going forward. And so rather than looking one or two weeks ahead, it’s most efficient to plan for today based on what you learned yesterday.

5. Schedule a Release Sprint

Even after the release is written and tested, most projects still have a lot of loose ends. For example, all of the documentation is written in technical jargon, which to an ordinary person makes no sense at all.

A release sprint is a bit like a dress rehearsal. It firms things up and makes software presentable and usable for external release. An effective release sprint brings in stakeholders from outside the development team to review the product, evaluate it and provide feedback.

Much of this preparatory release work has nothing to do with development at all. The backlog for a release sprint might include writing a FAQs page for new users to an application, or providing instructions for managers of the application on how to update features.

These documents use everyday language, unlike the technical language from the development sprints. It’s a good idea to create these documents just before the release, so that they include any last minute changes.

Taking the time for a release sprint ensures the final product is sparkling clean, presentable, and ready to be handed off. A release sprint functions a little differently from a development sprint. It may be a different length, and may also use a separate “definition of done” from the one used for writing code and testing.

You’ve probably heard the expression that “the best things in life aren’t things at all.” Some of our favorite things, such as nights out at the movies, evening walks in the snow and road trips to national parks, wouldn’t mean a whole lot if they didn’t include “things” like laughter, connection, friendship and love.

What do warm fuzzies have to do with non functional requirements in agile? As it turns out these two things are very much alike.

Not a few agile teams have banged away on a big project–planning iterations, completing user stories, producing increment in every sprint–only to discover during testing (or even later) that the product is not in line with the client’s expectations.

The client ordered a pizza, and the team delivered it, exactly to specifications: 16”, pepperoni, piping hot. Yet it lacked something fundamental. Maybe the service was lousy, the restaurant too noisy, the delivery time too long. The team thought it provided just what the customer ordered, yet it wasn’t what they ordered at all.

This leaves the team frustrated and flummoxed. When you play by all the agile rules, such as meet requirements, hold retrospectives and study the burn down chart, how can things go wrong? And how do you change things going forward?

If you’ve learned the hard way that non functional requirements cannot be ignored, even while they cannot be measured, then this post is for you. We’re going to look at how these hazy requirements butt heads with agile, and how to capture and measure their “uncapturable” qualities each iteration.

The Definition of Functional & Non Functional Requirements

Let’s start by defining just what functional and non functional requirements are.

Functional Requirements

A functional requirement is a measurable quality or characteristic in a completed project. It’s concrete and often can be seen.

For example, if the project is building a website, a functional requirement may be to build a registration page that includes inputs for both name and email. If the project is to write a song, a functional requirement may be that it includes four stanzas and a chorus.

Since they’re quantifiable and measurable, it’s easy to tell whether or not a functional requirement has been met. It’s as simple as checking something off a list.

Non Functional Requirement

A non functional requirement is a quality or characteristic of a completed project that isn’t directly related to its functionality. It’s neither tangible or measurable, but related to overall qualities the project possesses, or the conditions under which the project must be met.

Non functional requirements (NFRs) include characteristics such as usability, scalability, security, compatibility and performance.

For example, a non functional requirement of “usability” for a website would affect several facets of the project. Copy that’s easy to read, pages that load quickly and a layout that makes navigation between web pages intuitive all contribute to “usability.” However, each of these requirements is quite diverse, and none of them has measurable specifications.

Since they’re nebulous and indefinable and bleed into all parts of a project, then, it’s difficult to determine when a non functional requirement has been met. It’s not so simple as checking a box on a list and pronouncing it “done.”

Further Distinctions between Functional and Non Functional Requirements

Non functional requirements are executive level, big picture goals, whereas functional requirements are easily measurable, definable goals that get into the granular and specifics of the project at hand.

Requirements in the real world aren’t always so cut and dry as to fall into either of these two categories. Many exist in a grey area between the two.

Another distinction between these two requirements is that there are multiple ways to meet an NFR, whereas meeting a functional requirement is clear and straightforward. For example, say a project has a NFR to “increase sales.” This increase may be achieved in one of several ways, including improving the software, increasing the hardware capability or by hiring more employees.

Now that we’ve defined each term, let’s look at how capturing NFRs in agile iterations is a bit like fitting a square peg into a round hole.

The Problem With Mixing NFRs & Agile

Agile teams work efficiently. The agile method is brilliant in part because it ensures a team dedicates its time and energy to increasing the business value of the end project. To this end, each iteration produces increment that meets specific, measurable criteria. Many scrum teams have even developed a “definition of done” that covers all the criteria a task must meet before the user story is complete.

Some agile teams use a system known as “Elephant Carpaccio” which breaks down a long-term project into individual tasks, each of which can be completed in a day. This way, each and every day the team takes another step toward its stated goal.

Everything the team does is a step toward a measurable goal. It doesn’t spend a lot of time going down rabbit holes or building something that has no business value to the client.

A nearly exclusive emphasis on concrete, measurable goals, however, doesn’t jibe with NFRs. Just like two opposite personalities in a workplace, it’s tempting for the agile method to try and sideline NFRs, or even run them out entirely.

Because how can a product manager create user stories and groom a backlog around requirements as vague as “security”? And how does a team assign story points to a requirement as nebulous as “productivity”? How does a team produce increment if the entire sprint it’s working on the foggy notion of “usability”?

The acceptance criteria for a user story entails meeting the “definition of done.” It’s a tactical accomplishment that’s measurable. And non functional requests cannot meet this criteria.

Yet, as we’ve discussed, ignoring NFRs can mean entirely missing the project’s objective. Consider, for example, someone who seeks to improve their health by losing weight. “Overall health,” in this instance, is a non functional requirement, and “losing weight” a functional requirement.

If after a few months this person has lost 50 pounds, it may appear he’s achieving his goal. However, if you look at the larger picture and discover he continues to smoke five packs of cigarettes a day and eats mostly red meat and carbs, he’s not achieving the overall objective at all.

And so as difficult as they are to fit into a backlog or a sprint, ignoring NFRs isn’t an option.

Double-Edged Sword

All this is to say is that the danger of a team focusing only on NFRs is that they’ll go into a “black hole.” They have no increment to present at the end of an iteration. Since they haven’t achieved anything that adds specific business value, they don’t have any need to communicate with the client or with anyone.

On the flip side, the risk of a team focusing only on functional requirements is that they aren’t incorporating larger, big picture thinking into the project. They’re fixated on completing the daily tasks, on the minutia, and may well end up creating something that’s completely missed the mark.

How does a team mitigate both these risks, and marry these two extremes? Let’s go there next!

The Three Steps to Capture NFRs in Sprint Planning

Claiming to capture non functional requirements may seem like saying unicorns exist and that Bigfoot lives in the woods behind your house. But it’s not like that. It really can be done.

It starts by approaching NFRs differently from functional requirements. In a broader sense, NFRs are more like constraints than requirements. They’re the boundaries under which a project is executed, the parameters it works within at all times. The functional requirements are executed and completed within these constraints.

NFRs are like company culture in this sense. Although it’s difficult to see and sometimes to define, company culture in fact affects every aspect of the business: from the layout of the workplace, to the attire people wear to work, to the criteria for receiving bonuses and promotions, to the location where the holiday party is held.

Since they’re fundamental to the outcome of a project, NFRs are woven into the entire project, from the planning to the execution to the completion. Without them, something fundamental is missing from the project. And so NFRs are brought into consideration in every sprint planning session.

Yet how do you measure them and determine if they’ve been met? Here’s a simple three-step approach.

1) Prioritize the Non Functional Requirements

The first step is to determine what the NFRs really are. Don’t assume that usability is at the top of the list. Maybe the client values scalability first and foremost.

Completing this first step entails having an open discussion with executives and project stakeholders to get a clear idea of what they are looking to see in the end product.

2) Break the NFR Down

Recall that NFRs are so big and broad that they have many possible solutions. Once you know which NFRs are the most important, at this point it’s necessary to determine how they’ll be executed.

This is demonstrated more clearly with an example. Let’s say an executive wants to increase sales by 10,000 each day. This is a high-level NFR to increase productivity.

The team then determines if this goal is best solved by improving software, increasing the capacity of hardware, or hiring more employees.

Once a path is chosen, the team breaks it down further and determines the individual steps it needs to take. If it decides to hire more employees, this is executed by recruiting, interviewing, training, then hiring new people to do the job.

3) Include NFRs in Sprint Planning

When an NFR has been defined and broken down, it’s much easier to measure and achieve. In this final step, the team creates user stories around these individual steps and includes them in sprints.

For example, if the team decides to hire more people in order to achieve the NFR of increased productivity, then the user stories in the first sprint might be to define the job duties, write a job description and determine the pay. For the upcoming sprints, the team would create user stories around posting and promoting the job, then reviewing applications, and finally interviewing and hiring recruits.

It works the same with other non functional requirements as well. For example, if the NFR is security, and the team is building the registration page, then the user story might be to increase the strength requirement of the password. If the NFR is usability, then the user story might be to create a metric around how long it takes for a page to load. If the NFR is aesthetics, then a user story might be to coordinate fonts and colors within the website.

At this third step, a NFR starts to look very similar to a functional requirement. It can be evaluated per the criteria in the “definition of done” and checked off a list.

Although putting metrics around something like “user-friendly” seems vague, it is possible. As you can see, when broken down, NFRs have metrics and look concrete. This three-step method allows teams to incorporate NFRs into the backlog and assign them user points. They won’t be overlooked. Because they can’t afford to be!