In recent years the agile movement has greatly expanded and is now state of the art with its highest priority being to satisfy the customer through early and continuous delivery of valuable software. Its primary measure of progress is working software. How can agile software development help business people explain their needs so that business analysts can pass it on to the developers and testers without losing functionality?
There is still a gap between user stories with their acceptance criteria and developed code. User story acceptance criteria are not well defined and the parties involved do not know how the system should react with respect to its described functionality.
What is BDD?
Behavior-driven development (BDD) is an agile software development method which is based on agile values and principles. BDD, established by Dan North in 2006, was a response to the pitfalls of test-driven development (TDD) with the aim of delivering software that matters. So, behavior-driven development is implementing an application – or parts of it – by describing its behavior from the perspective of its stakeholders.
BDD combines agile requirement analysis with user stories and their acceptance criteria and a domain specific language. Each acceptance criterion is split into several detailed scenarios. These scenarios can be read and understood easily by testers and developers, as well as business people, to close the gap between user stories with their acceptance criteria and developed code.
Clik here to view.
Figure 1: Existing gap between user stories and code
Why use it?
The Standish Group identified success and failure factors and challenges for projects in its current CHAOS report. The three major reasons for success are user involvement (15.9%), executive management support (13.9%), and clearly stated requirements (13.0%). The three major reasons for failure are incomplete requirements (13.1%), lack of user involvement (12.4%), and lack of resources (10.6%). The three major challenges are lack of user input (12.8%), incomplete requirements and specifications (12.3%), and changing requirements and specifications (11.8%).
The survey differentiates projects into three resolution types:
- Resolution Type 1 (succeeded): The project is completed on time and on budget with all functionality as initially specified.
- Resolution Type 2 (challenged): The project is completed and deployed but over budget and time, and offers fewer features and functionalities than originally specified.
- Resolution Type 3 (impaired): The project is cancelled at some point during the development cycle.
Only 9% of the projects in large companies are successful. At 16.2% and 28% respectively, medium and small companies are more or less successful. A large amount, 61.5%, of all large company projects are challenged (Resolution Type 2) compared to 46.7% for medium companies and 50.4% for small companies. The majority of projects (37.1%) were impaired and subsequently cancelled (Resolution Type 3) in medium companies, compared to 29.5% in large companies and 21.6% in small companies .
As a business analyst, it is very hard to deal with those survey results. So I recommend using agile requirement analysis with BDD, focused on stakeholder value throughout the project.
How should you INVEST in good stories?
Creating agile requirements with BDD includes two common core elements:
- User stories in narrative language
- Scenarios in a domain-specific language
Functionality will be described without any technical aspect, assuming that developers know best how to implement them.
As a business analyst I missed user stories that followed Bill Wake’s
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
characteristics of good quality.
To reach these goals you start by using the app to evaluate the generic roles which are involved and by gathering their goals, and considering the given business goals with all stakeholders. Some good questions concerning the role could be as follows:
- Who are the users?
- Which users will use it in a similar way?
- Could these be aggregated into generic roles?
- Which attributes do those generic roles have?
Afterwards the goals and business outcomes of the generic roles should be figured out by asking:
- What functions should the software fulfill?
- Which functions are important?
- What preferences are available?
- Are there any limitations concerning technology or usability?
- What business goals should be achieved with the app?
- Do the goals of the generic roles match the business goals?
Then you cluster the business outcome into coherent topics and transfer them into large stories, or “epics”, and recheck them with the question: “Are they linked with the given business goals?”
Afterwards each epic is split into user stories to describe it in more detail. The requested functions should behave within the perspective of the user’s role. One way to create a user story where the relevant components can be easily distinguished looks like this:
User story
As a [role] I want to [do] [something], so that I [receive business benefit].
The following questions are intended to give an idea of the objectives of “something” and “do”:
Something
- What is the content of [sth.]?
- Which rules have to be checked for [sth.]?
- What are the optional/mandatory aspects of [sth.]?
Do
- Who needs to [do] it?
- When has it to be [done]?
- When is it completely finished?
- What possible rules have to be implemented to avoid incorrect input?
If a user story does not have a business benefit for the given role, it is obsolete.
The answers allow you to define acceptance criteria to understand the app’s behavior from the perspective of each involved role and to confirm the required functionality. Writing user stories with their acceptance criteria sounds very easy, but it is very hard work.
Why is Gherkin SMART?
Each user story with its acceptance criteria will be split into one or more business scenarios in a domain-specific language. Gherkin is a computer-based domain-specific language for one or more common domains with a specialized syntax to describe the behavior of the apps without defining any implementation details. Gherkin is used in BDD because its syntax
- exists in the 37 most popular languages,
- is easy readable and understandable as a documentation for stakeholders, and
- supports automated testing in several technologies (e.g. Perl, Python, Ruby on Rails, JAVA, C#) with a variety of tools.
Gherkin syntax uses spoken language with keywords as steps. The GIVEN step describes the known state (precondition) of the app before the user (or external app) starts interacting with it. The input (action) performed by the role is characterized by the WHEN step. The THEN step describes the desired testable outcome related to the business benefit in your description. The AND step allows you to read the scenario more fluently while adding preconditions, actions, or testable outcomes. The OR step characterizes an alternative way (e.g. precondition) of reaching the testable outcome while passing the following steps. Finally, the BUT step usually describes an exception case at the end after passing the previous steps.
Scenario [some determinable business situation]
GIVEN [some precondition]
OR [an alternative precondition]
AND [some other precondition]
AND [yet another precondition]
WHEN [some action by the role]
AND [some other action by the role]
AND [yet another action by the role]
THEN [some testable outcome is achieved]
AND [some other testable outcome is achieved]
BUT [some testable exception is achieved]
Clik here to view.
Figure 2: Overview of user story with acceptance criteria and scenario for an acceptance criterion
All steps can be combined to describe your acceptance criterion. With BDD you can ensure that your requirements suit a
S – Specific
M – Measureable
A – Achievable
R – Realistic
T – Time-boxed
way of working. A user story can easily become much more difficult than necessary. Keep in mind that all participants have to be able to read and understand the requirements. A good user story is short and simple.
To do it in a SMART way, it is very important to answer the question: “Which and how many scenarios are needed?” If the number of scenarios per acceptance criterion is not high enough
- to understand the user story scope
- to get the stakeholders’ confirmation
- to validate the requirement
- to estimate the workload
- to unit test the criterion
- to system test the criterion
you have to create more scenarios to ensure a common understanding.
Please note that BDD is a design strategy and not a test strategy. If it comes to testing, the scenarios will represent a good starting point for several testing activities, but there is much more to testing than those scenarios.
Is it worth it?
By moving from traditional business analysis to BDD, you enable cross-functional collaboration with several feedback loops throughout the hierarchy and between all participants. So, business people and business analysts derive user stories with their acceptance criteria and scenarios from requirements to confirm their reliability and understandability. Developers write their code based on the same agile requirements and test it automatically. Test analysts use the same stories and add more details, as well as new stories required for system and acceptance testing.
BDD strengthens a project’s key success factors, such as user involvement and clear statements of requirements, and therefore enables you to deliver software that matters. If you do not separate requirements from tests, you get executable, validated, and value-driven requirements with concrete examples of the app in use. You avoid project challenges and failure factors by eliminating lack of user involvement and user input, as well as incomplete requirements and specifications. In times of test automation, BDD provides a very good base with its combination of functional requirements and test cases. In addition, those test cases can be automated in several technologies using a variety of tools.
Clik here to view.
Figure 3: Closing the gap between user stories and code
BDD is much easier to use than any other technique of requirement engineering that I have discovered in practice. BDD provides a specialized framework to focus on value-driven and well described functionality. It does not cover all aspects of documentation. It is completely different to any other traditional technique or agile approach, such as TDD, because you reduce information loss and create business-readable scenarios with several steps and testable outcomes. Furthermore, all technical decisions remain the developers’ and architects’ responsibility.
BDD can be used for requirements engineering in any agile or traditional environment. I used BDD at one of the largest automobile financial services providers in Europe to implement a collaboration platform in a waterfall environment. All participants highlighted BDD’s good usability and great level of understanding. The project was very successful in terms of functionality.
The post Agile Business Analysis with Behavior-Driven Development (BDD): INVEST to be SMART appeared first on Agile Record.