I had the pleasure of speaking to the IIBA chapter in Cowtown last night. That’s Fort Worth for those of you unfamiliar with the Great State of Texas.

Total attendance was 15 people and we had some good conversation. There were not many questions during the presentation, but enough to let me know they were listening. I was touched a few folks from the IIBA Dallas chapter drove over for the meeting, thanks.

Holly Millet, a guest at the event, was kind enough to run the camera and record my presentation. If you are interested in seeing this, then please let me know and I’ll put it online and provide a link.

—

This presentation is at an introductory level, aimed at Business Analysts who have not worked in an Agile or Scrum for a significant period of time. I do not by any means cover everything it means to be an Agile BA, but rather focus on the elements of good stories, including writing Acceptance Criteria in a Given – When – Then format. This latter section should provide some value for anyone not already involved in the format. Unfortunately, with only an hour, I include enough content to push out interactive activities.

In August I coined the term Behavior Based Requirements to describe Given-When-Then and some of the related concepts to BAs. If this is your first introduction to this format for capturing and communicating value, you can find much more information on my resource page here.

—

As usual, I am posting a version of the slide deck here for attendees who want to view a copy of the slides. I typically shift the slide order just a tad to make more sense for reading at your desk. This slide deck includes references and mentions the mighty shoulders I stand upon when presenting.

I am excited more people are talking about Behavior Driven Development (BDD) for Business Analysts. I know of three different presentations about the topic in Wisconsin this year! I had no idea this state was such a hotbed for BAs.

I am giving two different versions of my presentation this coming month. The first presentation is titled Reducing Risk in Software Projects Using Behavior Based Requirements for the 6th Annual Project Management Symposium at Jindal School of Management, The University of Texas | Dallas. If you are in the Dallas area, then please come over and participate August 16, 2012.

The symposium theme is “Project Management in a Risky World.” This presentation is targeted directly at explaining BDD for the audience, Project Managers working in waterfall environments. This is the first conference I was asked to prepare a paper to accompany the slides. You can view the Abstract, or download both the Paper and accompanying Slides.

My second presentation this month is How to Build Better Requirements with Behavior Driven Development on Tuesday, August 21 as part of the IIBA Spotlight Series Webinar. This is my first ever Webinar and I’d love to have you participating no matter where you live. This presentation is a benefit of being an IIBA member. If you are not a member, please consider joining.

Update: In effort to get more feedback, I am including the text of the Reducing Risk paper here. If you appreciate my kindness (saving you an extra click), then please repay me with a comment below.

Reducing Risk in Software Projects Using Behavior-Based Requirements

Jeffrey S. Davidson

Abstract

Requirements are the key to implementing the vision of a business or client. Software project failures are a significant factor to lost capital and operational expenses, lost time, and eventually lost opportunity and revenue. While project failures have been well documented, less attention is paid to the similar costs from unused and underutilized features within software projects.

With upwards of 45% of software features never used and an additional 32% rarely used it is time to pay attention to the core needs and jettison the wasted effort, expense, and code that is bogging down project success.

A key methodology in correcting this problem is Behavior Driven Development (BDD). Originally developed to help developers understand the business needs, it has grown beyond its roots and is capable of making a significant impact on curbing excess demands, requests, and gold plating.

Often seen as solely an Agile software development technique, this toolset provides insight into the core functionality of a software product and can lead to significant improvements in user experiences by removing unnecessary functionality before it becomes embedded in modern and future systems.

Introduction
Understanding the goals and objectives should be the first step of every project. In traditional project delivery, the outcomes and quality of a project stems from a firm understanding of the basics, i.e. time, scope, and cost. While each of these three may be fixed outside of the project, the final deliverables depend on how well they are understood and implemented within the project.

When discussing the success and failure of software projects, there are more references to the CHAOS Report by the Standish Group than any other metric. I want you to look at the following table and understand software projects now, and apparently always have, do not deliver on their initial objectives. Compared to their objectives, 63% of projects are challenged or fail! This number would be shocking if it was a one-time event, but it’s not. It is just the latest number in a 20-year trend line.

Corporate development shops continue to disappoint: A fall 2004 Forrester survey of 692 technology inﬂuencers—those who hold the information technology (IT) purse strings—indicated that nearly one-third are dissatisﬁed with the time it takes their development shops to deliver custom applications, and the same proportion is disappointed by the quality of the apps that are ultimately delivered. One-ﬁfth of respondents are unhappy on both counts. [Emphasis added]

The problem goes deeper though. Eveleens and Verhoef quote Standish,

“Standish defines a successful project solely by adherence to an initial forecast of cost, time, and functionality. The latter is defined only by the amount of features and functions, not functionality itself. Indeed, Standish discussed this in its report: ‘For challenged projects, more than a quarter were completed with only 25 percent to 49 percent of originally specified features and functions.’”[3] [Emphasis added]

Summarily, we have failed projects, we have significant portions of functionality sitting unused, we have unhappy executives, and we have challenged projects delivering less than half the functionality.

There are many ways to run a failed project, but only a few ways to run a successful one. Some of the recurring and significant contributors to these problems are centered on understanding the scope of the problem and solution, involvement of key personnel with the project team, and defining detailed requirements of what needs to be built.

Capers Jones, the pre-eminent expert on software quality stated,

“Although clear requirements are a laudable goal, they almost never occur for nominal 10,000 function point software applications. The only projects I have observed where the initial requirements were both clear and unchanging were for the specialized small applications below 500 function points in size.”[4]

This is the crux of why I propose the standard formats for eliciting and communicating requirements are deficient and need to be revisited. Software delivery project problems will not cease when we have a better understanding of software requirements, but we can start making radical improvements to the decrepit state of affairs in today’s projects.

Thinking like an investor
Chris Matts proposes there are only three reasons for developing software; making money (or expanding the organization’s mission), saving money, or protecting money, including risk avoidance or compliance dictated. Consequentially, every software development project is an investment.

Gene Kim and Mike Orzen “calculated the global impact of IT failure as being $3 trillion (US) annually.”[5] This includes $100 billion of waste just from S&P 500 companies and at least $250 billion in failed IT projects. Software delivery projects are failing.

A primary issue is many project failures is Project Managers, Business Analysts, and project teams understand the list of features to be delivered, but do not understand the project’s purpose. Many individuals are good at running calculations to determine Cost-Benefit Analysis and Return-on-Investment. Even more teams know where to find the list of features to be built and tested. What teams do not have a deep understanding of is why the business investment is being made and how the organization will benefit from it. They do not shepherd the project as if their own capital was at risk.

The truth of every software project, despite the thinking of so many of my peers, is the value of an IT system is entirely based on the expected outputs or outcomes. Systems are not built because they are esthetically pleasing or to meet the experiential design goals.[6] Rather, IT systems are built to make, save, and protect money.

Over the last decade a number of tools have been developed to assist development teams with grasping how to approach problems based on this mindset. The first of which is Feature Injection.[7]

There are three steps to feature injection:

Hunt the value – Build a model based on your desired results

Inject the features – Use the model to decide what features pull us toward the value

Spot the examples – Use stories to find variants to the happy path and have a conversation

Step 1: Hunt the value
The value of a software project needs to be boiled down to a well-understood model. Models should be specific and targeted towards the desired business value. This value must be both clearly defined and communicated to the entire project team. Communicating specific goals and the delivery outcomes expected aligns the team with the organization.

Models require only a concise statement about the output or outcome and how this will be achieved. It does not require a significant document and can often be conveyed in a single paragraph.

Step 2: Inject the features
It is by looking at a project through the lens of what value needs to be created we can spot the features that must be added, or injected. This list of features should be only those items that pull us towards the greater value. This is not the same activity as recording a list of desirable or demanded features. Rather, this becomes a focused set of features, driving towards specific outputs defined within the model.

Step 3: Spot the examples
Examples are the real world test of what a system needs to be responsive towards. Using the steps above will find most paths to a positive output (value). This step is focused on both ensuring negative paths are understood and the system can be validated as successful. Examples become the communication tool to ensure the system is adequately built.

Of course, the unstated fourth step is to follow information smells. That is, look for gaps in understanding, particularly around the information and data being used. This step allows you to both confirm your models completeness and discover what may be missing. When you find something that may be missing, whether a feature or example not adequately covered by the existing set, repeat the above steps to fill in the hole.

Communicating through examples (Behavior-Based Requirements)
The second tool I want to introduce to you is a structured, natural language for learning, writing, and communicating requirements. I want to re-introduce you to storytelling.

“Storytelling is among the oldest forms of communication. Storytelling is the commonality of all human beings, in all places, in all times. ” Rives Collins, The Power of Story: Teaching Through Storytelling [8]

The oldest written story is The Epic of Gilgamesh[9], from the land of Ur. It was likely written about 2,700 BC. The actual history of storytelling is unknown. No one knows if the first stories were told to calm an upset tribal member about a sudden storm or why catastrophe occurred on the most recent hunt. No one can say the first time a story was told to explain someone else’s behavior. What we can say is storytelling evolved to give meaning and purpose.

Example: Storytelling
I want you to imagine being alive three millennia ago, when written language was rare. You live in a tribe with your family and friends. There is nothing anyone in the tribe can do to surprise you. You know everyone else too well. You have been through too much together to be very surprised by anyone. You were born into this tribe and if you had to, you would die for this tribe. You know and trust everyone else in the tribe. And they trust you.

Tonight your tribe is sitting around after a great hunt. You and your tribe have killed a bison and tonight you feast. After the feast, and the children have started to settle down, you sit around the fire. You get quiet and still, but you are excited. Expectant. Everyone knows what’s going to happen next, the tribal elder is going to start telling a story.

We use stories to communicate. We don’t communicate in facts. The tribal elder didn’t say, “Run. Many hills. No water. Throw. Parabolic arc. Dead. Eat now.”

No, the tribal said, “The winter was long and it has been many moons since our bellies were full. Yesterday we learned of a great beast, great enough to feed us all. Early this morning we woke and ran from when the sun came up until it was at it’s highest in the sky. We are so glad the beast was moving slower than Ugg runs! We were incredibly thirsty, but knew the right shot would bring us victory! Sam pulled back his arm and threw his best spear, the best throw of his life. It was amazing and now we eat like the gods.”

And the reason the tribal elder tells his stories with a setting, a sequence of events, and a conclusion, is because that is how we are wired. The human race has been telling stories around the campfire since time we first grunted at each other. The first record of telling stories may be the sons of Cheops entertained their father with stories, but we have been telling stories since time immemorial because it is what works best.

As part of a team, we need to understand and acknowledge the human species is wired to communicate using stories. To not tell stories is to deliberately hurt the chance of your teammates, your organization, and your customers understanding. It becomes simple, telling stories are good. Not telling stories is harmful.

The Wrong Focus
Our focus over the last twenty years has been to build correctly. Teams spend a great deal of money and effort to obtain and master the latest tools. Yet despite significant investments, despite significantly faster workstations, despite untold dollars spent on training, the products we deliver are barely beyond what they were in 1994.

Our focus on the building process is only part of the solution. The time has come to focus on building the right product. Gojko Adzic presents the following chart in his latest book, Specification by Example:

What I am proposing is stories are a key tool in a new focus, a focus on building the right product.

This is especially true when we deal with large, complex subjects. Rich Hickey recently presented “Simple Made Easy.”[11] His points are especially poignant for teams striving to make a difference with the software projects. They were:

We can only hope to make reliable those things that we can understand

We can only consider a few things at a time

Intertwined things must be considered together

Complexity undermines understanding

Building large software projects is a difficult endeavor. We needed to spend the last few decades ensuring we have the proper tools for the job. Success requires more than just tools. Success will come when we take the time and effort to enable greater understanding. Storytelling is the means to achieve this goal. Using behavior-based requirements uniformly promotes this across all types of projects. They are simply a means to capture the functionality of a system as described through fine grained, focused bits of behavior. These small behavioral examples are told in a story format, allowing easy access to readers of all kinds.

Structure of Stories
The structure for our behavior-based requirements is:

Context – You and your condition

Event – What action do you perform?

Outcome – What is the observed response?

When writing these requirements, they should be captured using the following language:

Given … (context)

When … (event)

Then … (outcome)

After using this technique for a couple years, I have specific recommendations for effectively writing behavioral requirements. First, while the requirements need to be cover exact behaviors, they should be design agnostic. It is not appropriate to include language implying either user interfaces or system architectural decisions within the statements. This level of detail takes practice to master as it is typically less than included within traditional requirements, i.e., “The system shall….”

Second, the language used needs to be natural and not stilted, contrived, or technical. If you cannot get an executive, a data entry clerk, and your grandmother to understand the same sentence, you may not be writing clear enough. Read your statements out loud. If they sound more like a novel than the technical instructions for programming your electronic clock, then you are probably on the right path.

Third, the language needs to use business terms. This means the storytellers (users, executives, and subject matter experts), the people documenting the stories, and the team developing the stories will come to understand more about the business domain. This is a good thing and in keeping with delivering value over a list of features.

Fourth, amplify and reinforce the stories with testable data. For developmental and validation purposes, this proves the delivered code is correct. The story is correct. The understanding is correct.

Power of Stories
There is an underlying presumption we have both misunderstandings and unknown unknowns inherent in existing techniques. In seeking to both document those places and fill them with understanding, the practitioner asks about usage scenarios. These stories are filled with behavior and from this behavior design patterns emerge. The end result of using stories and examples correctly is a shift towards better elicitation techniques.

The simplicity of the grammatical structure belies the power this technique brings over the course of a project. Converting needs and actions to words is inherently messy. Our language is inexact and not designed to convey preciseness. Yet we need a level of precision and accuracy in our project communication. This technique allows us understand and validate finite behaviors in a large context.

This technique also encourages the discovery of what needs to be done to achieve project objectives. Using the discovered requirements throughout the project allows for the understanding project teams have been missing. No longer will one level of understanding be locked in a document team members do not read or have access.

Conclusion
Based on the rates of software delivery project success, your projects should already have a risk calculation around being challenged or outright failing. With a proper and universal understanding of the scope and goals, this risk will be reduced. I propose using behavior-based requirements as a key technique for achieving your common understanding, even it were to raise your project cost or timeline.

This technique is not meant as a direct challenge to the traditional requirements elicitation and documentation. Rather, this is a refinement of how requirements are drawn out and shared. This technique reduces requirements risk in a manner existing requirement structures cannot.

Using this technique we begin to literally capture conversations. And in capturing, we are sharing instead of merely interpreting. The need for business interpreters can be supplanted with understanding. The roll of interpreter and gatekeeper changes to one of communicator and bridge builder. Rather than attempting to push information uphill to a team, understanding can be shared and pulled as it is needed. Sponsors and project teams have concrete and comprehensible proof they are working towards the same ends.

“BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

“Standish defines a project as a success based on how well it did with respect to its original estimates of the amount of cost, time, and functionality.” Eveleens and Verhoef argue CHAOS Reports measure software projects in comparison to their initial estimates and other factors. As such, they may not be accurate due to problems in the initial estimate.

This paper does not dispute problems with initial estimates, but rather presumes the sponsors of such projects expected them to deliver as promised, even if the estimates are poor.

Models require only a concise statement about the output or outcome and how this will be achieved. It does not require a significant document and can often be conveyed in a single paragraph.

Step 2: Inject the features
It is by looking at a project through the lens of what value needs to be created we can spot the features that must be added, or injected. This list of features should be only those items that pull us towards the greater value. This is not the same activity as recording a list of desirable or demanded features. Rather, this becomes a focused set of features, driving towards specific outputs defined within the model.

Step 3: Spot the examples
Examples are the real world test of what a system needs to be responsive towards. Using the steps above will find most paths to a positive output (value). This step is focused on both ensuring negative paths are understood and the system can be validated as successful. Examples become the communication tool to ensure the system is adequately built.

Of course, the unstated fourth step is to follow information smells. That is, look for gaps in understanding, particularly around the information and data being used. This step allows you to both confirm your models completeness and discover what may be missing. When you find something that may be missing, whether a feature or example not adequately covered by the existing set, repeat the above steps to fill in the hole.

Communicating through examples (Behavior-Based Requirements)
The second tool I want to introduce to you is a structured, natural language for learning, writing, and communicating requirements. I want to re-introduce you to storytelling.

“Storytelling is among the oldest forms of communication. Storytelling is the commonality of all human beings, in all places, in all times. ” Rives Collins, The Power of Story: Teaching Through Storytelling [8]

The oldest written story is The Epic of Gilgamesh[9], from the land of Ur. It was likely written about 2,700 BC. The actual history of storytelling is unknown. No one knows if the first stories were told to calm an upset tribal member about a sudden storm or why catastrophe occurred on the most recent hunt. No one can say the first time a story was told to explain someone else’s behavior. What we can say is storytelling evolved to give meaning and purpose.

Example: Storytelling
I want you to imagine being alive three millennia ago, when written language was rare. You live in a tribe with your family and friends. There is nothing anyone in the tribe can do to surprise you. You know everyone else too well. You have been through too much together to be very surprised by anyone. You were born into this tribe and if you had to, you would die for this tribe. You know and trust everyone else in the tribe. And they trust you.

Tonight your tribe is sitting around after a great hunt. You and your tribe have killed a bison and tonight you feast. After the feast, and the children have started to settle down, you sit around the fire. You get quiet and still, but you are excited. Expectant. Everyone knows what’s going to happen next, the tribal elder is going to start telling a story.

We use stories to communicate. We don’t communicate in facts. The tribal elder didn’t say, “Run. Many hills. No water. Throw. Parabolic arc. Dead. Eat now.”

No, the tribal said, “The winter was long and it has been many moons since our bellies were full. Yesterday we learned of a great beast, great enough to feed us all. Early this morning we woke and ran from when the sun came up until it was at it’s highest in the sky. We are so glad the beast was moving slower than Ugg runs! We were incredibly thirsty, but knew the right shot would bring us victory! Sam pulled back his arm and threw his best spear, the best throw of his life. It was amazing and now we eat like the gods.”

And the reason the tribal elder tells his stories with a setting, a sequence of events, and a conclusion, is because that is how we are wired. The human race has been telling stories around the campfire since time we first grunted at each other. The first record of telling stories may be the sons of Cheops entertained their father with stories, but we have been telling stories since time immemorial because it is what works best.

As part of a team, we need to understand and acknowledge the human species is wired to communicate using stories. To not tell stories is to deliberately hurt the chance of your teammates, your organization, and your customers understanding. It becomes simple, telling stories are good. Not telling stories is harmful.

The Wrong Focus
Our focus over the last twenty years has been to build correctly. Teams spend a great deal of money and effort to obtain and master the latest tools. Yet despite significant investments, despite significantly faster workstations, despite untold dollars spent on training, the products we deliver are barely beyond what they were in 1994.

Our focus on the building process is only part of the solution. The time has come to focus on building the right product. Gojko Adzic presents the following chart in his latest book, Specification by Example:

What I am proposing is stories are a key tool in a new focus, a focus on building the right product.

This is especially true when we deal with large, complex subjects. Rich Hickey recently presented “Simple Made Easy.”[11] His points are especially poignant for teams striving to make a difference with the software projects. They were:

We can only hope to make reliable those things that we can understand

We can only consider a few things at a time

Intertwined things must be considered together

Complexity undermines understanding

Building large software projects is a difficult endeavor. We needed to spend the last few decades ensuring we have the proper tools for the job. Success requires more than just tools. Success will come when we take the time and effort to enable greater understanding. Storytelling is the means to achieve this goal. Using behavior-based requirements uniformly promotes this across all types of projects. They are simply a means to capture the functionality of a system as described through fine grained, focused bits of behavior. These small behavioral examples are told in a story format, allowing easy access to readers of all kinds.

Structure of Stories
The structure for our behavior-based requirements is:

Context – You and your condition

Event – What action do you perform?

Outcome – What is the observed response?

When writing these requirements, they should be captured using the following language:

Given … (context)

When … (event)

Then … (outcome)

After using this technique for a couple years, I have specific recommendations for effectively writing behavioral requirements. First, while the requirements need to be cover exact behaviors, they should be design agnostic. It is not appropriate to include language implying either user interfaces or system architectural decisions within the statements. This level of detail takes practice to master as it is typically less than included within traditional requirements, i.e., “The system shall….”

Second, the language used needs to be natural and not stilted, contrived, or technical. If you cannot get an executive, a data entry clerk, and your grandmother to understand the same sentence, you may not be writing clear enough. Read your statements out loud. If they sound more like a novel than the technical instructions for programming your electronic clock, then you are probably on the right path.

Third, the language needs to use business terms. This means the storytellers (users, executives, and subject matter experts), the people documenting the stories, and the team developing the stories will come to understa

Our speaker at this week’s IIBA Dallas Chapter meeting is very ill. With only 48-hours, it’s not much time to get a new speaker, so I will be presenting! Please come on over this Thursday to hear me present on Feature Injection and Behavior Driven Development (BDD).

Unleashing the Power of Behavior Driven Development

There is a special place where the hidden treasure of great requirements are found. It’s not that what we have today is bad, but it’s time to move beyond writing stodgy requirements no one else is willing to read. Diagrams are great for communicating, but most of the time you need more than just pictures. And user stories a really good step forward, but many of us find they are still missing something.

The secret may lie in Behavior Driven Development (BDD). The fabulous thing, besides the cool name, is this is easy to learn, easy to use, and produces better stories, requirements, tests, and code!

This presentation is for analysts who already know how to right requirements, but want to move to something more productive. This is an introduction to a new technique, using natural language to describe both the value and features of a system and each interaction.

Come learn about writing requirements and acceptance criteria in business language (for your customers) that are clear and complete (for your developers) and super-duper easy to double-check (for the testers)!

Learning Objectives:

Understand the fundamentals and benefits of Behavior Driven Development

Learn how to write better requirements & acceptance criteria using natural language and business terms

Tap into the power of permutations to ensure test cases are complete.

BABOK Alignment:

This talk aligns with the Agile Extension to the Business Analysis Book of Knowledge (BABOK).

See: Chapter 4: Techniques / Get Real Using Examples (pp. 81-84)

About the Speaker:

Jeffrey Davidson is a Principal Consultant with ThoughtWorks, a leading Agile development firm with a passion to improve how businesses design, build and evolve software. He also serves as President of IIBA Dallas Chapter.

Jeffrey is a consulting Business Analyst, Mentor, Coach, and Trainer. An engaging and entertaining speaker, Jeffrey speaks with passion to audiences across the country on business analysis and agile development.

Jeffrey has had many titles, including Director of Business Analysis & Quality Assurance for UTI, Business Analyst for Dell, Systems Engineer for Raytheon, and Product Manager for Ebay. He is a Certified Product Manager (PMC) and a Certified Scrum Product Owner (CSPO).

Jeffrey’s focus is helping organizations and Business Analysts transition to Agile, delivering great requirements, and building world-class analyst teams.

I am very excited to be talking this morning at the Building Business Capabilities Conference 2011. The organizer, Rising Media, has done a fabulous job with over 900 attendees with 4 related, but separate focus areas.

My presentation, Using Behavior Driven Development and Feature Injection to Build Better Software will be @ 11:30 AM in Regency 1. I do hope you will come and hear the presentation.

Notes:

Click for a PDF of my PowerPoint presentation deck, with full slides & transitions. EXTRA: This has just a touch more than the “public” PDF deck you will find at the conference website. It’s something extra for the folks who follow me on twitter & read this blog. All rights reserved, etc.

If you can make it to the talk, then please help me make this a conversation, not a boring presentation.

Huge thanks are due to everyone who helped me learn more about this topic. With a special shout-out to Paul Hammant for the introduction to BDD and Chris Matts for the kind conversation.

Any oversights and mis-statements are someone’s fault. I’m not sure who, but someone is to blame.

As you can see from the widget on the right, I am speaking at the Building Business Capabilities conference this year. I’m super excited to be included as part of baf: Business Analysis Forum, billed as The Official Conference of IIBA. As far as I am concerned, there are three great confereces for BAs in North America, and this is one of them!

They have released the Conference Preview Guide for this huge conference, but I have included my information below so you don’t have to look too hard!

Building Better Acceptance Criteria Using Behavior Driven Development and Feature Injection

It does not matter if you have a great idea for a software product; you have to communicate this to the developers building your system. Beyond user stories, developers need to understand the value and function they are building. They need good, or better yet great, acceptance criteria.

The secret to writing great acceptance criteria lies in Behavior Driven Development (BDD) and Feature Injection. The fabulous thing, besides the cool names, is they are easy to learn, easy to use, and produce better stories, requirements, tests, & code!

The heart of BDD and Feature Injection lies in using natural language to describe the value and features a system contains. Following a simple grammatical structure leads both writers and readers to understanding the goals and how they will be delivered. This process uses real examples, in business terms, to describe the behavior of the application.

While there are significant benefits for business partners, developers, and testers; one of the key benefits is how this turns Business Analysts and Product Owners from gathers of information to distributors. Rather than constantly pulling information from others, this provides BA’s the tools for pushing information out.

Attendees will leave understanding:

Fundamentals and benefits of Behavior Driven Development and Feature Injection

How to write better requirements / acceptance criteria using natural language and business terms

How to easily develop real-world test cases to prove the feature is working as desired

About the speaker:

Jeffrey Davidson is a Lead Consultant with the global IT consultancy, ThoughtWorks, with deep experience as a mentor, coach, and trainer. An engaging and entertaining speaker, Jeffrey speaks with passion to audiences across the United States on business analysis and agile development.

Jeffrey has had many titles, including Director of Business Analysis & Quality Assurance for UTI, Business Analyst for Dell, Systems Engineer for Raytheon, and Product Manager for Ebay. He is a Certified Product Manager (PMC) and a Certified Scrum Product Owner (CSPO).

Jeffrey’s focus is helping organizations and Business Analysts transition to Agile, delivering great requirements, and building world-class teams.

User Stories Are Easy – Repeat Performance

How to Turn Old-fashioned Requirements into Great User Stories

Some of you missed the chance to hear Jeffrey speak at BusinessAnalystWorld: Denver, and this is your last chance to hear him talk on this topic during the coming year!

Stop struggling! The transition to Agile and Scrum, is not as difficult as most Business Analysts fear. The format is different. The tools are different. The timeline is different. Your co-workers might be different. Maybe your title is different too. It doesn’t matter, because requirements do not change with the tides and they do not change with the methodology.

Come and participate in this deep dive into User Stories, learning how your familiar tools work in Scrum.

Session objectives:

Be able to describe the elements of a good user story

Explain how traditional requirements tools compare and fit in with user stories

Answer the question, “What happens to all the stuff I no longer document?”

Scrum: Wrapper? Savior? Troublemaker?

Scrum seems to be taking over software development, but how does it fit into a SDLC? What are the differences? Do they make a difference? This is a chance to discuss real world implementations, tools, goals, fears, and implications.

This early morning conversation is with the Arizona Chapter of Technology Executives Networking Group (TENG), a professional community of selected CIO’s, CTO’s, vice presidents and directors of technology. Find out more about TENG here.

UPDATE [June 13, 2012]: The above image is not mine, I took it without attribution from http://www.limina-ao.com/approach/agile.html. I got a message from Jon Fukuda and he was very kind to let me leave the image if I gave proper attribution. Lastly, this image is not included within my Creative Commons 3.0 license. You really need to drop Limina a note if you want to use their intellectual property. Thanks, Jon. I appreciate you being a good guy despite my behavior.