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?