A couple of posts ago, I wrote about Feature Injection. Here’s a quick summary of how I do it:
- Vision: A primary or core stakeholder has a vision which will save money, make money or protect revenue.
- Goals: As well as his own goal, the goals of other stakeholders will have to be met too, in order for the vision to go live.
- Capabilities: To deliver the goal, we provide the users and the system with the capabilities to do something.
- Features: Most capabilities could be achieved with people, paper and pen, but we like to help by providing software. A feature is a widget, or a part of an application, or a page on a website, which supports the capability.
- Stories: Features are quite large, so we break them into vertical slices on which we can get feedback.
- Scenarios: A scenario is an example of a user using the system. We can use scenarios to explore the requirements, discover things we haven’t thought about and break up our features and our scope.
- Code: Finally, we get to see the vision become reality!
I also wrote about two patterns I use in conversation with scenarios: context questioning, and outcome questioning.
Given a context, when an event happens, then an outcome should occur.
- Is there any other context which produces a different outcome for the same event?
- Is this the only outcome that’s important, or does something else need to happen too?
Normally when we think of scenarios, we think of a user using the system. However, we can use these two patterns at scale, as well.
Given a stakeholder, when we deliver this software, then we should meet his goals. Is there any essential stakeholder whose goals we haven’t met? Is there any other goal we need to meet at the same time?
As an example, think of writing software for air traffic control. Obviously the pilots are stakeholders. What about the regulatory authorities? What are their goals? Will the airlines be able to stop us going live? Are there legal concerns?
Given a feature, when we deliver this software, then the user should have the capability to do something.
As an example, consider a trading system. Does the feature for booking a trade provide the whole capability? What about auditing? Approvals? This is also a great way to discover other missing stakeholders!
Given a vision, when we deliver this software, then we should protect our revenue.
Will this really stop our customers from going somewhere else? Is there some context in the market which we’re missing? If we deliver this software, are there any other possible outcomes or repercussions? Perhaps Facebook or RBS could have used this pattern…
By questioning what should happen, and asking, “Should it?”, we can use the same familiar patterns at scale to discover even more potential scope, explore our ignorance and reach a common understanding or find places where there isn’t one.
Wouldn’t it be nice if we could write tests for those examples at scale, too?
Liz Keogh, lunivore 
Writing tests for examples at scale is what I am experimenting in recent years but may be, in a slightly different context.
My company is in the “Control / Competence” quadrant of the Schneider Culture Model (99.998 reliability is our differentiator). Hence, we have to wrap our Agile projects by waterfall (i.e. water-scrum-fall). We also need to implement ERP systems.
Moreover, our applications are mostly business process workflow oriented. Hence, between Capabilities and Features, we have tons of business processes and IMHO, Gherkin (As a … I want … so that … Given … When … Then …) is not a good ubiquitous language candidate for workflows. My suggestion is to use the traditional UML process activity diagram (process flowing thru stakeholders). We can still have Deliberate Discovery to figure out alternate flows and missing stakeholders.
From the activity diagram, we drill down one more level to execution steps with expected results. This is the preliminary Specification By Examples in the business process level. It serves four purposes:
(1) Fit-for-purpose analysis (ERP) / Deliberate Discovery (custom build)
(2) Specifications for developers
(3) Acceptance criteria
(4) Documentation & training
Then we can continue with waterfall, agile or hybrid. But in parallel, while programs are being developed and functionally tested, we will beef up business processes’ execution steps by adding details such as the prepared test data and UI guide – make it executable.
Surprisingly, SAP has already produced similar documents years ago and it is online and free — SAP best practices (http://help.sap.com/bestpractices). For each business process, there are two documents. (1) UML process activity diagram and (2) Business Process Documents (BPD), which consists of executable steps with instructions of entering pre-configured test data into screen fields. It is an executable specification in the business process level.
My point is that we can write examples for Capabilities and Features at scale. In this level, examples can be in formats other than Gherkin, like traditional UML process activity diagram with executable guide and prepared test data.
Hi Michael, SAP rollouts are one of the things that I suggest you don’t use BDD for, so this matches my experience too. Unless you’re doing something genuinely new, BDD probably isn’t going to help so much. If you’ve got something that you can deliver with 99.998% reliability, it’s probably very low-variance, and any examples will already be very well understood and boring.
It’s for this reason too that I don’t recommend using BDD with scenarios like logging in or CRUD web forms. There are better ways to get requirements for those as well.
Hi Liz, thanks for your reply.
First, 99.998 reliability is referring to my company’s core business, not IT. Hence, it is my company’s culture in which we write software. Nevertheless, they are willing to participate in SCRUM teams after we added some degree of formalization.
For BDD, yes you are right. I cannot use BDD, user stories, Gherkin, SCRUM, etc to ERP rollout. But how about moving up one level to Business Processes and apply Specification by Examples?
As a … I want … so that … –> traditional UML process activity diagram
Given … When … Then … –> executable steps with instructions of entering pre-configured test data into screen fields
It is a specification of business processes as well as executable test.
I am not sure if it is something genuinely new but coincidently enough, SAP published the “best practices” which we can freely install. For many common business processes, we have UML process activity diagrams and executable steps with instructions of entering pre-configured test data into screen fields. They are specification of business processes as well as executable test. It is not SAP specific. Any software can do this in the business process level.
Hence, the first step in the requirement stage is to customize these “Examples”, such as adding branches and alternating flows. Then, in parallel to the normal ERP development, QA will prepare data, alter the execution steps and make these customized “Examples” executable again. I believe that Executable Specification in the business process level is achievable and worthwhile even in ERP implementations.
In my blog’s new V-model, the top two levels can be applied to ERP and waterfall projects. The bottom two levels are specific to Agile approaches. All 4 levels are based on the idea of executable specification.
Pingback: Estimating Complexity | Liz Keogh, lunivore