22/36 : BDD, Theme, Epic, Feature & Story
Build with user behavior in mind.
🚀 Exciting News! Our Product Management Job Board is Now Live! 🎉
Find your dream job effortlessly with our revolutionary AI-powered job preference service!
To explore the possibilities and find your next career move, visit our job board at https://www.productmindset.io.
We would love to hear your feedback and suggestions for new features. Together, let's shape the future of product management job search!
Behaviour Driven Development
This is an introduction to behavior-driven development – an approach to development that improves communication between business and technical teams to create software with business value. This guide is for both technical and business professionals and explores how BDD can benefit projects of all sizes, and how to implement it with confidence. It is structured to reflect the flow of the BDD process.
When launching a new digital project, there can be a disconnect between:
the business being truly able to define the desired outcomes;
the developer’s understanding of what needs to be built; and
the business’ understanding of the technical challenges its requirements may present.
Behavior-driven development (or behavior-driven development) can help achieve all of the above and ultimately, helps a business and its technical team deliver software that fulfills business goals.
What is BDD
Behavior Driven Development (BDD) is an agile software development practice that encourages collaboration between everyone involved in developing software: developers, testers, and business representatives such as product owners or business analysts.
BDD aims to create a shared understanding of how an application should behave by discovering new features based on concrete examples. Key examples are then formalized with natural language following a Given/When/Then structure.
History of BDD
Behavior-driven development was pioneered by Daniel Terhorst-North back in the early 00s, as he explained in a 2006 article called Introducing BDD. It grew from a response to test-driven development (TDD), as a way to help programmers on new agile teams “get straight to the good stuff” of knowing how to approach testing and coding, and minimize misunderstandings. BDD has evolved into both analysis and automated testing at the acceptance level. Liz Keogh, another BDD pioneer, started writing and speaking about it extensively beginning in 2004.
Why BDD?
BDD describes application behavior from a user’s point of view. Overall, the main goal of BDD is to improve the collaboration between all stakeholders involved in developing software and form a shared understanding among them.
Benefits of practicing BDD:
Reduced Rework / Shared Understanding: Concrete examples of expected system behavior foster a shared understanding by being specific enough for developers and testers while still making sense to business participants. Think of a BDD scenario like a bug report that is written in natural language and posted before the system has been implemented. It describes the steps to reproduce (Given/When) and the expected outcome (Then) without the symptoms (unwanted behavior) that usually triggered the bug report.
Faster Feedback: Example scenarios describe focused, granular changes to the system under development. This enables teams to evolve the system in small steps while keeping it potentially shippable, allowing for shorter release cycles and faster feedback.
Effectiveness: Since you extend the system in small increments, you can validate business value earlier and avoid unnecessary features. This prevents gold-plating and makes the overall implementation of the system more effective.
Lower Cost: Driving automated acceptance tests through test-first BDD scenarios is much cheaper than post-automating acceptance tests. Teams practicing ATDD (Acceptance Test Driven Development) use their shared understanding to develop the feature and the test automation, while teams separating development and test automation need to interpret and fine-tune scenarios multiple times. This causes extra effort and can lead to misaligned interpretations. Additionally, test automation based on scenarios that were used to drive the implementation has a better focus and more relevant assertions. This leads to higher test automation coverage and more relevant test automation scenarios, which reduces regression errors and efforts for manual checks.
Single Source of Truth: Specification through examples that are guarded with automated acceptance tests is an always-up-to-date description of the current system behavior (“Living Documentation”). This provides a single source of truth for the team, business stakeholders, and important external parties like regulatory authorities or partners relying on the system specification. Here you can view an example.
User Satisfaction: By focusing on the needs of the business, you get satisfied users — which translates to customer loyalty and better business outcomes. The higher degree of test automation frees more time for manual exploratory testing and yields fewer errors in production, especially when shipping new versions at a high cadence. More frequent, high-quality releases enable rapid response to evolving user needs and dynamic market pressures.
Code Quality: Using Acceptance Test Driven Development has a positive impact on code quality: it promotes emergent design that ensures loosely-coupled, highly cohesive architecture and avoids over-engineering and technical debt. This ensures that a system stays testable and maintainable– and that it can be quickly changed to support new requirements without sacrificing stability.
Principles of BDD:
BDD has three basic principles:
Enough is enough: Advance planning, analysis, and design have diminishing returns. We must not do less than what is we need to start, but more than that is a futile effort.
Delivering value to our “stakeholders”: If you find yourself doing something that does not deliver value or increase your skill/ability to deliver value, quit and do something different.
Everything is behavior (Behavior): Whether at the level of code, application or beyond, we can use the same thought and the same language to describe behavior at any level of granularity.
Behaviour Driven Analysis
We explore how software can help address a business problem by asking, what is known as, 5ws1H. This technique is intended to develop insight and allows us to explore new avenues and better understand existing ones.
We approach BehaviourDrivenAnalysis in a structured way to minimize the risk of missing anything useful. Use Cases are a useful tool for establishing the boundaries of a system, in the sense of understanding what the system is (and more importantly is not) responsible for. A Use Case in this context describes an Actor (someone or something in a Role) interacting with some exposed interface to our system.
The important distinction between behavior-driven Use Cases and the traditional Rational version is that the Use Case must specify the business value of the interaction. At this level, the description of the value can be quite broad or vague, but it must be there (because we will drill down into it later). We use Use Cases as a launching point to understand the value at a finer level of granularity, which in turn allows us to prioritize the delivery of functionality as we go along. We talk about prioritizing later on when we discuss BehaviourDrivenPlanning.
What is a Theme?
A scrum theme is the highest level of the story hierarchy. It describes a view of a tangible product or an abstract goal. A product owner further breaks down a theme into one or more epics.
Let's treat these as strategic business objectives in the form of items. They provide business context for decision-making and help you navigate the course of your organization. They also affect the work items you are going to load in the different value streams.
What are Epics?
In Agile project management, epics are larger bodies of work, which can be the building blocks of the upper mentioned initiatives/themes. They should be more specific and measurable so that you can see their contribution to the primary goal.
These Agile epic examples will consist of several tasks, work items, or user stories that need to be completed over a more extended period.
Depending on their size, they can also turn into bigger projects. Regardless of how you choose to name them, the important thing here is to ensure that those epics/projects are related to the main theme/initiative and support the high-level goal of penetrating the project management software market.
Creating an epic
When creating a new epic consider other planning and organization tools your team may already have in place. Creating epics around a team’s quarterly goals or OKRs is a great start. When creating an epic, consider the following:
Reporting — Create epics for the projects that managers and executives will want to keep an eye on.
Storytelling — Use epics, and the stories that roll up into them, as a mechanism to tell the story of how you arrived at the current state of a feature or product.
Culture — Let organizational culture dictate the size and granularity of an epic.
Time — Most development teams rely on estimation frameworks instead of time, but it’s a worthwhile gut check to make sure your epics will take a couple of weeks to complete. Not too long and not too short.
Break down an epic
Breaking down an epic into more practical stories helps in understanding a project and maintaining momentum, but it can be a daunting task for the uninitiated. There is no one-size-fits all solution for creating stories from an epic, but there are a lot of good options to consider:
User role or persona — Create a unique story for each user persona. “Quicker login for new visitors,” “quicker login for return customers,” etc.
Ordered steps — Break down the process and create a story for each step.
Culture — Let team norms dictate if a story is a quick task or a week-long project.
Time — Barring another agreed-upon convention, design stories that can be completed in one print or less.
There is no universal definition that draws a line between a big story and an epic. In general, any scope of work that the team estimates at “weeks” (or longer) to complete, rather than “hours” or “days” should be considered an epic and broken down into smaller stories.
What is a feature?
A feature is a consistent function or service of the product.
Features represent parts of the product that bring significant value to its users. Features are usually too big to big worked on directly so they are broken down into smaller business units: stories. As far as planning is concerned, producing a feature is expected to last several sprints. Features help materialize the vision and share it to the agile team and the stakeholders.
“A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria.”
Ideal feature criteria
It should provide business value.
It should be estimable - it must have enough definition for the development team to provide an estimate of the work involved in implementing it.
It should be small enough to fit within one or two iterations - therefore, if it is too big, it should be broken down further.
It should be testable - you should understand what automated or manual test a feature should pass in order to be acceptable to the customer.
Managing feature requests
Firstly, it’s worth highlighting that not all feature requests are the same. They can be broken out into three different types:
Unresolved problems with an existing feature e.g. the customer has experienced a technical issue and is unsure how to make progress.
Feature improvements e.g. the customer is not sure on how to achieve a certain result with your product.
A brand new feature request e.g. the customer is asking for something that’s not yet supported in your product.
How to prioritize feature requests
Once you’ve gathered feature request data from customers, along with their relative importance, you need to find a way to prioritize the suggestions.
Potential factors you’ll want to include are:
Customer lifecycle. You might want to respond to customers who contact you in the first days after sign-up, as they are at the highest risk of churning.
High-value users. As they are the customers paying you the most money, you’ll want to pay particular attention to their feedback. Especially if this group plays a crucial role in your long-term growth.
The difficulty of implementing the proposed improvement. Some feature improvements might be relatively straightforward to implement and provide 10x value to customers. On the flip side, some improvements look simple but require months of complex engineering.
The volume of feedback. Logging the number of times each individual product improvement has been suggested can help you make a case for bringing a particular feature request to the product team.
What are user stories?
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.
A user story is an informal, general explanation of a software feature written from the perspective of the end-user or customer.
The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.
User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.
Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.
User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. These larger structures ensure that the day-to-day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.
Why create user stories?
For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.
User stories serve a number of key benefits:
Stories keep the focus on the user. A To-Do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve an end goal.
Stories create momentum. With each passing story, the development team enjoys a small challenge and a small win, driving momentum.
How to write user stories
Consider the following when writing user stories:
Definition of “Done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For Whom? If there are multiple end-users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
Once the user stories are clearly defined, make sure they are visible for the entire team.