Improving Software Development Communication with Behavior-Driven Development

Behavior Driven Development (BDD) Konstantin Kudryashov https://inviqa.com/blog/bdd-guide When launching a new digital project, there can be a disconnect between: The business being able to define the desired outcomes, and The developer s understanding of what needs to be built, and The business understanding of the technical challenges their requirements may present. BDD helps a business and its technical team deliver software that fulfils business goals.

BDD An approach to development that improves communication between business and technical teams to create software with business value. Context Software development is often deluged by overwork, translating directly into wasted time and resource for both engineers and business professionals. Communication between both parties is often the bottleneck to project progress when engineers often misunderstand what the business truly needs from its software, and business professionals misunderstand the capabilities of their technical team.

BDD Given the miscommunication and complexity, the end product is often technically functional, but fails to meet the exact requirements of the business. BDD is a process intended to aid the management and the delivery of software development projects by improving communication between engineers and business professionals. In so doing, BDD ensures all development projects remain focused on delivering what the business actually needs while meeting all requirements of the user.

Key Benefits of BDD All development work is traceable back directly to business objectives. When software development meets user need that s good for business. Efficient prioritization ensuring that business-critical features are delivered first. All parties have a shared understanding of the project and are involved in the communication. A shared language ensures everyone (technical or not) has thorough visibility into the project s progression. Ensuring that software design matches existing and supports upcoming business needs.

Key Benefits of BDD Improved quality code reducing costs of maintenance and new project risk. All development work is traceable back directly to business objectives. Software development that meets user need and is good business. Efficient prioritization with business-critical features are delivered first. All parties have a shared understanding of the project and can be involved in the communication.

BDD: divided into two parts First: the practice of using examples written in Ubiquitous Language to illustrate how users will interact with the product and with each other Ubiquitous Language a shared, common vocabulary that the entire team shares when discussing software! Second: Using these examples as the basis for automated tests. As well as checking functionality for the user, this ensures the system works as defined by the business throughout the project lifetime. Note: business value and user requirement are never secondary during development

Starting with a Goal Every behavior change should help the business or the company to achieve its goals by increasing revenues, improving usage or reducing waste. In BDD, projects are delivered in sets of capabilities. Capabilities are the features in software development that enable users to be more efficient. Example: automating the ordering process of an ecommerce store or automating warehouse management. In order to meet business requirements, you need to understand exactly what you want the software to achieve from a business perspective. In BDD, this is the business goal: the driving force behind the project.

A good business goal! SMART S M Business goal is Measurable A Business goal is Attainable R Business goal is Relevant T Time-bound A Bad example We are going to generate more revenue by making more sales A Good example We are planning to achieve a 15% increase in revenue through our online channels in 6 months Business goal is Specific

Having a SMART goal Helps to focus the project Most importantly, it allows the impact of the project to be measured. This ensures that any and all development can be linked back to the business goal and ensures the end product meets business requirements.

Impact Mapping Once the short-term goal for the project has been defined and the timeline agreed, you can begin planning how to achieve that goal. In software development, trying to achieve goals by adding new features to applications is common and is also the reason behind many of the most infamous project failures. The alternative: justifying any new feature requires identifying (explicitly) how the features will support the users behaviors or the company s business.

Impact Mapping A technique for outlining all of the alternative ways to reach the decided goal The technique works by analyzing users behavior We assume that software cannot achieve business goals on its own and the only way software can get us closer to the goal is by supporting particular human behaviors Example: an online shop doesn t bring you money on its own; people bring you money by purchasing products from it.

Impact Mapping Looking at software through a prism of those who will use it is a valuable way to plan and direct the project development An Impact Map has four distinct levels 1. A Business goal 2. One or more actors 3. One or more impacts and 4. One or more ways to support or prevent these impacts.

Start with the business goal; it is the Map s root node Grow the map out from the goal by first identifying all the actors that could help or prevent the project from achieving the goal (e.g. the customer or the team) Each actor could have multiple ways to help or hinder achieving the goal, these are impacts.

Start with the Business Goal as the map s root node The last layer of an impact map defines what the project or delivery team can do in supporting or preventing particular impacts from occurring This is the layer where the software options come into play.

Value and Complexity analysis In collaboration-heavy Agile methodologies like Behavior-driven Development, it is important to clearly distinguish and agree on priorities. This is done by using two techniques: Value and Complexity Analysis Value Analysis helps to quickly identify low-cost, high-value features in the Product Backlog Complexity Analysis helps us to choose the right development and collaboration approach to the project as a whole, as well as to each individual feature (One of the most interesting Complexity Analysis frameworks BDD practitioners use is called Cynefin)

Planning using Examples Again, misunderstanding and wrong expectations are the primary reason behind overwork and waste in the software industry Developers often misunderstand what a business actually wants or needs, and business people often misunderstand what developers are actually capable of This contributes to an environment where the developers deliver, but do not meet the needs of the business and can miss a number of opportunities

Misunderstanding Using examples to remove ambiguity and misunderstanding Example: Given a task to add to an existing ecommerce project the following feature: Include the VAT (Value Added Tax) and delivery cost to the total price of the customer s order Using the following set of business rules: The VAT is 20% Delivery cost for small order (less than 20) is 3 Delivery cost for medium size order (more than 20) is 2

The ambiguity The rules The Value Added Tax (VAT) is 20% Delivery cost for small order (less than 20) is 3 Delivery cost for medium order (more than 20) is 2 The rules do not specify whether to add tax before or after the delivery cost is added ? What is the rule when the delivery cost is exactly 20 ? and what happens if there are multiple products in the customer s order?

Removing the ambiguity Adding examples to the rules removes the complexity Provide both rule and an example (or examples) For example: Given an order is priced at 15, then the total order price should be 21 Given an order is priced at 25, then the total order price should be 32 Given a order is priced at 20, then the total order price should be 26 The intent is to remove potential uncertainty associated with the Business rule and how it is to be implemented

Usage-centered Design Examples illustrate human behaviors One of the biggest promises of BDD is to deliver software that matters In order to achieve this, understanding who and how users will benefit is essential Why? To much software is designed and built with little consideration for how it will be used and how it can proved value and best support the work its users will be doing

Usage-centered Design Usage-centered design is an approach to software development where every single bit of deliverable functionality should focus on the intentions and patterns of users To define different software user interactions, the users are grouped into so-called abstract actors Example: changes to a catalog Before the implementation stage, identify who the audience (users) is for the feature In a short discussion with the Product Owner and/or Business Analysis, the goal is to learn how users look for a very specific product Their search approach is to use ambiguous terms

Usage-centered Design Finding what they are looking for using ambiguous terms provides no help! Being unable to find the product via search, they attempt to find the product by searching the catalogue The result is that potential customers may be lost With user-centered design, the feature request changes from the need for a large task of reworking the catalogue to providing search capability that responds to ambiguous search requests

Focusing on users behavior is the key concept behind usage-centered design and one of the most important concepts in BDD It s not just identifying examples of human behaviors and interactions but we also understanding the point of view of the users! By focusing on the users and their behaviors, and then understanding who the system is built for, the goal is to deliver software that meets the needs of all who use it!

Analyzing User Behaviors The task is to analyze behaviors of people that will use the system, and then analyze the different options and alternatives that would best meet their needs. This allows for the possibility of different but more effective implementations and optimizations. Caring about user behaviors not only helps in delivering the software itself, but in building the technical system to directly meet the needs of users.

Ubiquitous Language The challenge: groups of people that operate in different business spheres both sides use the same language and even the same words, but the words imply a different meanings to both sides For example, in building a Banking App, you might be asked to implement an account feature in the next iteration Without experience with this particular business or company, an assumption may be that this feature relates to user accounts or user management accounts when it may actually refers to the introduction of credit/debit accounts into the system.

The consequence! The result the design and development of an account system could be anywhere from a couple of weeks (using Agile) or years (using Waterfall) building an account system before learning that the client didn t actually want some or all of what was delivered. This situation has a descriptor: The Feedback Delay or, in this particular case, The Cost Of Translation

Behavior Driven Development solution Reduce the size of feedback loops and enforce the example-based conversation about each feature before design and development Just asking for examples is not enough, because different sides will use different language to produce examples, eventually causing discrepancies. The solution for this problem is the concept the BDD community borrowed from DDD (Domain Driven Design) Ubiquitous Language.

Ubiquitous language Ubiquitous language is a language created by developers and the business in order to discuss features and talk effectively in examples It is not a technical language or a business language, but a combination of both The benefit of both sides agree agreeing on shared understanding of the meanings of the language used, increases the likelihood of both sides understanding of each other! Ubiquitous Language is an integral part of BDD To use examples effectively requires a shared language (meanings and understandings)

Ubiquitous language Examples The most common and adopted format for developing and communicating examples is the BDD format Given-When-Then using a natural way that people communicate It follows what is a very simple structural agreement: 'Given describes the initial context for the example 'When describes the action that the user or stakeholder performs 'Then describes the expected outcome of that action

Example-1 Clients provide examples of how they expect a particular capability to be delivered When I do this, they this should happen Feature: Returned items go back to stock Example: Given a customer previously bought a black sweater from me And I currently have three black sweaters left in stock When he returns the sweater for a refund Then I should have four black sweaters in stock

Example-2 Clients provide examples of how they expect a particular capability to be delivered When I do this, they this should happen Feature: Returned items go back to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Example: Given that a customer buys a blue garment And I have two blue garments in stock And three black garments in stock When he returns the garment for a replacement in black Then I should have three blue garments in stock And two black garments in stock

User Stories (Given-When-Then) A user-story identifies a stakeholder, a business effect, and a business value A user-story also describes several scenarios, each with a precondition, a trigger, and an expected outcome Each of these parts is identified by a more formal part of the language (the term Given might be considered a keyword, for example) and followed by a language that the development team and business created together. In the previous example, the ubiquitous language includes terms like stock , replacement and returns

Introducing the Three Amigos Common mistake that teams commit when starting to work with examples Assuming that writing down these examples is the most important part of the process, and that giving this responsibility to a single person is enough Behavior Driven Development is a highly collaborative process Talking in examples requires not only more than one person to have that conversation, but requires different perspectives and experiences in order to be efficient and effective

Product Owner or Business Owner One of the core ideas behind BDD is that no single person has the full answer to the problem This is the The Three Amigos idea All angles can and should be covered if you bring together the insights from a business person, a developer and a tester Business roles such as a Product Owner or Business Analyst own and define the business value and risk evaluation domain Their insight and input is extremely important if you want to deliver software that matters (these people will generally ask questions like Is it valuable? Do we really care about this? )

Developers and Testers Developers, in the most part, remain in the so-called solution space Their input will give you an invaluable context into how much detail the feature should have in order to be implementable Testers usually represent the problem space; they see flaws happening in the system even before development commences

The BDD loops Independent of the platform, technology or language needed to deliver an application In order to succeed, every application needs to constantly adapt. Markets change, technologies change, our understanding of business changes and we get new opportunities every day. The way we deliver software should reflect this ongoing process of change.

The BDD loops In order to support the pace of change we face in most modern projects, adopting scenario-based test-driven development is not enough Scenarios tend to describe the behavior of the application as a whole, on a higher, modular level. But, in order to support the slow growth and change of these modules, drastic and much faster changes in the system underneath them are needed A way to support big, visible changes in the application behavior is to do a lot of small (sometimes invisible), but very stable changes inside it

Testing Unit tests are small pieces of code, which have a sole purpose to evaluate a small isolated part of the system In BDD, these are called object specifications These are treated as examples of how small isolated parts of the system should behave, rather than a way to test them In order to support the ability for systems to change, safely making big changes (supported by automated scenarios), as well as the small ones (supported by automated object specifications) are needed

Following the BDD process The goal is to create a software solution that is not only well- built and tested, but also what the business actually needs Every line of the production code, configuration or even specification is directly linked to its particular scenario, which itself is linked to the ultimate project business goal The result is knowing how much business value each line of our code must deliver If it doesn t provide value as a result of market or business reasons, knowing exactly which lines of code need to replaced or even removed is essential! This is the way BDD ensures it constantly delivers software that matters.

BDD Videos .An Introduction to BDD from Konstantin Kudryashov https://www.youtube.com/watch?v=njcHzGYv7nI 4:39 Minutes Dave Snowden The Cynefin Framework One of the most interesting complexity analysis frameworks BDD practitioners use is Cynefin a sense-making framework that helps make sense of the problem at hand so that you can act accordingly https://www.youtube.com/watch?v=N7oz366X0-8 8:37 Minutes