From a software developer’s point of view, come join me for a pop-culture, restaurant and fast food referencing presentation that utilizes behavior driven development to address some of the problems we still face in an agile world.
So your team has made the transition to agile and your work is broken down into user stories. It makes perfect sense to break work down into smaller chunks, but now you're running into problems with estimation and communication. Your team is delivering value but it’s been discovered that user stories are thrashing through the analysis, development and QA processes. What is going on here?
Come a software development process with a deceiving name: behavior driven development. Behavior driven development (BDD) is a process that captures how a software system functions with sets of acceptance criteria. From a developer’s perspective this appears to be test driven development at a higher level with potential automation of those tests. However, if you take a step back and look at the bigger picture, it’s about functioning better as a team to deliver value to your clients.
We will take a look at the process of gathering standardized acceptance criteria from the perspective of the four main stakeholders in a project: the product owner, analyst, developer and QA. Teams involving more stakeholders in the grooming process can experience increased collaboration and better communication. User story estimations can bemore accurate and domain specific knowledge and terminology become ubiquitous as user stories move through the development cycle. Standard terminology propagates into software and creates living documentation within the code base. Software developers have increased productivity while creating leaner and better software with the process of TDD. These are a few advantages to BDD and there are more to explore. There are no silver bullets to anything so we will also address the disadvantages as well.
