Every day, organizations are becoming more dependent on applications to increase business competitiveness and penetrate new markets. Because of this ever-growing dependency, the number of different trends that will help shape an application grows as well: initiatives, market trends, business needs, requirements, themes, epics, features, user stories, etc.

Every application development project I have been involved with had two very clear constituencies: business stakeholders, who are involved in defining a product or service direction from the perspective of the business; and the DevOps team, which is responsible for building, testing, and delivering the product or service outlined by the business stakeholders. One constituency is focused on defining what needs to be built in order to surpass customer expectations and create compelling competitive differentiators. The other is tasked with interpreting those definitions and translating them into meaningful information so individuals across the development lifecycle can build, test, and deliver the right thing.

While this all sounds straightforward, the truth is that capturing what a product or service should provide varies across roles, responsibilities, and organizations. Trying to use a single approach to accommodate everybody’s communication needs is not possible.

When people get confused along the DevOps communication path, everyone loses, but especially the customer. This article outlines how to bridge the communication gap between the business stakeholders and the DevOps team to be sure you are creating the applications you should be creating—and that will delight your customers.

Business Stakeholders Focus On Customer Expectations

Roles involved in defining the direction of a product or service range in titles. Product managers, product marketing managers, key customer liaisons, sales representatives, and the services delivery team all have a hand in shaping a product.

These different stakeholders across the organization collect and organize information in slightly different ways, yet they need to eat, sleep, and breathe a common goal: building an experience their customers will value. They deliver this value by creating unique, efficient, and valuable differentiators to set their products and services apart from the competition.

Investing the time in gathering and organizing business needs is critical in understanding where to take a product. The top four places to start gathering this valuable insight are from customer feedback, market trends, competitive analysis, and analyst reports.

Realistically, you should expect to have representation from multiple stakeholders across the organization. But this shouldn’t lead to mass confusion; it should lead to focused, accelerated collaboration between the DevOps team and the business stakeholders, which will lead to the right results.

Agile Development Teams Live by the Backlog

Agile practitioners create, validate, break down, estimate, and rank user stories in the backlog. All that effort is focused on helping the development team understand what is expected to be delivered.

Deciding what to build is a matter of the agile team having enough information in a story so they can:

1. Estimate: The story needs to be cohesive and clear enough so the team can understand it, size it, and estimate.
2. Deliver in a single iteration: Stories should be small enough to be delivered in a single iteration, because multiple iterations could lead to confusing results.
3. Test it: Every story needs to have documented acceptance criteria so the team can decide the best test strategy and create test cases to verify the delivery of the story within any given build.

As iterations go by, the backlog starts to change in size and form. The backlog can get larger with the addition of user stories to support new trends, like development research spikes, defects, technical debt-related issues, etc., or it can shrink due to the removal of stories based on deprecation or replacement by other stories. The backlog’s form can changethanks to stories spreading based on prioritization exercises.

Given that the backlog is the single source of work description agile teams deliver against, the evolution of the backlog reflects the evolution of what’s going to be delivered. If stories should represent what will be delivered, shouldn’t they reflect what the business stakeholders understand is needed? In other words, shouldn’t the agile development team write them to communicate the business needs?

Or should business stakeholders adapt their process and practices and start writing down their business needs, initiatives, or any other type of business related requirements as user stories?

Meeting in the Middle

The reality is that neither the business stakeholders nor the development team should have to change their practices and processes in order to deliver better applications faster. They should have the liberty of capturing and expressing their perspectives of a given business need in different ways, yet also be able to easily establish and maintain the relationship across those perspectives so everyone can understand what and how things are getting delivered.

The business stakeholders have to understand how the business needs have been broken down into stories by the development team, and how they are currently prioritized; when the priorities change in the backlog; and what that change would mean to any given business need.

The agile development team has to focus on incrementally delivering functionality that adds value to the business using their agile principles, processes, and tools, and making sure that the backlog only has stories that represent the details and priorities the business stakeholders requested.

Bringing these principles together and bridging the communication gap between the business stakeholders and the DevOps team will lead to building applications the customers expect and will enjoy.