BDD: What it is and why we should care

It’s hip to be agile and cool to TDD, but what the heck is BDD (Behavio[u]r Driven Development? Where’s the intersection between TDD, ATDD, and BDD? More importantly, can it help my team focus better, or deliver faster? Yes!

We will walk through what BDD is, what it isn’t, and what it could be for your team. Part lecture, part conversation, and a teeny-tiny bit of practice; this session will be an irreverent look at this fabulous technique.

Cliff Notes version: BDD is about understanding and delivering functionality people use. If your software provides features for people, then come hear why BDD rocks!

TinyStories

How to Improve Your Requirements with Tiny Stories

I presented How to Improve Your Requirements with Tiny Stories at ProjectSummit & BusinessAnalystWorld held in Boston on October 21-22, 2013.

I firmly believe using the Given – When – Then of Behavior Driven Development (BDD) is relevant for business analysts. This talk is probably my best presentation of the material in the last few years.

You are welcome to view the accompanying presentation below. I sill share the link for the accompanying video upon request (and after I upload it to YouTube).

https://speakerdeck.com/jeffreygoodreq/how-to-improve-your-requirements-with-tiny-stories

BAWorld: How to Improve Your Requirements with Tiny Stories

Stop writing boring requirements!

No matter how much you love them, they often get in the way of communicating. The secret to good communication isn’t writing more of the same requirements, it’s in doing it differently. Instead of stale requirements you should tell tiny stories! Seriously!

During this presentation we will talk about writing requirements with little stories, sometimes known as Behavior Driven Development (BDD), Specification by Example, or Given-When-Then. In the IIBA Agile Extension to the BABOK, it’s called Get Real Using Examples (4.6.1). The key isn’t the many different names, it’s about structuring your requirements based upon behavior. And using this to ensure everyone from user-to-developer-to-stakeholder understands the functionality and goals.

Come and learn about Tiny Stories and how it will help you keep your project on track.

LINK

BDDXNYC: Using ATDD to Build Customers That Care

Agile Testing & BDD eXchange NYC 2013

Using ATDD to Build Customers That Care
In this engaging experience report, we will present 3 different views – Developer, Tester, Business Analyst – of implementing Acceptance Test Driven Development in a complex, data-driven domain. Hear how we used ATDD for building a ubiquitous language across the entire team, promoting faster feedback, and cultivating a culture where product owners were deeply invested in the quality of both every deliverable and the system as a whole.

Your presenters: Lav PathakSam Hotop, Jeffrey Davidson

Skills for Success: Professional Development Day @ IIBA Minn / St. Paul

I will be giving a new version of my talk about Behavior Based Requirements at this year’s Professional Development Day in Minneapolis / St. Paul. I am excited because I have reworked the entire presentation to both show my passion and give attendees a chance to practice using the Given-When-Then requirements format.

The conference title is Skills for Success: Evolving as a Business Analyst and my presentation is “How to Use Behavior Based Requirements to Build Understanding & Save Your Project.”

The event is on Monday, April 15 at the Earle Brown Heritage Center outside of Minneapolis (registration link). This is one of the premiere PDD events in North America and I am honored to be speaking. If you are in the area, please come, engage, and learn from the outstanding speaker line-up and local BA community.

 

Post conference update: Here is the published version of my slides:

LaoTzu(310x398)

Test Driven Retrospectives

TL;DR: Retrospectives can lead your team to becoming a powerhouse. One method of ensuring you making real improvements is Test Driven Retrospectives, where you define the desired state during the retrospective. By writing provable statements ahead of working on the task, you ensure everyone has the same understanding and knows what successful change looks like.

Measuring Requirements May Reinforce Bad Behavior

Have you ever heard this phrase?

“What gets measured, gets done.”

It contains huge truths about human nature, or at least my nature. I pay more attention to something when someone else is paying attention to it. I didn’t have to study the Hawthorne Effect to know this. Looking at my own life, there are lots of examples where if the boss was looking, I did my stuff. Where they didn’t care to look, I soon learned it was safe to ignore this area. And I often did.

More relevant to being a Business Analyst, I was brought into one company to train their new BAs. We spent lots of time covering the basics and then we started working on projects. The documentation was very uneven between the BAs (including me), so I said “Everything has to be peer reviewed before it goes out of the team.” And within a couple months everyone was writing great requirements. Really great. A couple months later, after we had stopped our internal reviews, the clarity and readability of our documentation was in the toilet. We had fallen back to our old habits. Just knowing a peer was going to review our work led everyone to do better work. There is no doubt in my mind, measurement and feedback can and do improve performance.

Unfortunately, most requirement metrics don’t help a BA, a project, or a team. They hurt it.

Typical Requirement Metrics

Measuring requirements can be difficult. Here’s a list of easy-to-gather requirement metrics:

  • Quantity (of use cases, requirements, user stories, process flow diagrams, etc.)
  • Volatility due to scope changes
  • Volatility due to technical & design changes
  • Volatility due to missed requirements
  • Volatility due to changes to existing requirements
  • Volatility due to clarification required
  • Defects due to requirements
  • Schedule variance due to poor or missing requirements
  • Tool compliance
  • Process compliance
  • Comparisons of the above versus:
    • initial estimates or baseline
    • time
    • project phase
    • project size
    • scope

These metrics have a couple elements in common. First, they are relatively easy to measure and calculate, presuming you have the right tools in place. I think many requirement management systems have been sold because for the first time companies will have metrics about requirements! Second, they all help ensure a team is builds correctly and in accordance to the original vision of the product.

Value?

I think it is important to ask, “How do these measurements benefit a team or project?” When I look at the above metrics, the focus seems to be on comparing requirements from one phase to the next, from how well did we understand the needs at the beginning of the project to how what was built at the end, to ensuring the process was followed. These all help teams “build right.” Which is important, but I think it is significantly more important to ask if the team is building the “right product.” Take a look at Gojko Adzic‘s chart from Specification by Example:

This chart describes my very real concern about requirement metrics. They help us build right. They help us ensure everything is checked-off the list, but none of the metrics push us to break the mold and build something great. They help us build something we planned months ago. I want to reinforce BA behaviors that push us to ask hard questions, pushing us up the value stream. I want us willing to take a new direction because we can see a project could be better. We should love killing projects because the value has already been reached, or never will be.

Behavior Reinforcement

If you want to improve teamwork, you need to reinforce behaviors that support acting like a good team member. If you reward people based on individual behavior, you are undermining the goal of improving teamwork. Similarly, it’s not uncommon to find metrics being misused. Sometimes the problem is minor, metrics are unused and the only impact is the wasted effort to gather and analyze them. Other issues include inappropriately punishing a team because of metrics and unintentionally focusing more on metrics than on delivering business value. None of these are part of the initial goal when a company or team decides to track information, but they are pretty easy to find.

Better choices

When you have to measure requirements, the first thing I want measured is their quality. First, define what a quality requirement ( or use case, or user story, or . . .) looks like. Then audit everyone against the standard. This ensures the quality of what BAs produce stays high. If your team is currently using a different style, template, or process for every project, this step will also push for more process compliance.

In a similar vein, I encourage teams to ensure everything goes through a peer review. I’m not sure metrics around this are especially valuable, but it might help with enforcement.

Lastly, think about the dimensions in Gojko’s chart above. Think about what’s really makes a difference. Fellow ThoughtWorker and Agile Manifesto signatory, Jim Highsmith has a great talk on this and often discusses with executives interested in enterprise agility. You should read his post and learn more about the most important metric of all, delivered value.