Good stories provide Value!
In SAFe, there are two story types: User and Enabler.
A User story directly impacts the user, customer, or stakeholder of the product, service or system.
An Enabler story is the ‘other work’ that enables the delivery of the User story. Example is the ‘Spike’ — this is a type of an enabler (exploratory enabler to be exact) that is geared towards research … to explore functional or technical options.
Both story types are valuable stories.
An agile team’s goal is to deliver the most value within reasonable time. Therefore, every user story must provide some value to the user; every enabler story must provide some value that indirectly impacts the user.
User story — since it directly impacts the user — has the user’s voice.
Example: As a bank customer I can withdraw money off the bank’s ATM so that I can have cash on hand.
What about the underlying ‘other things’ that are needed to happen in order to fulfill the aforementioned User story? Systemic activities like: ‘system to check the balance’, ‘system to throw error message’, ‘system to print receipt’, ‘system to dispense cash’, etc. How are these written? Each of these ‘systemic activities’ could potentially spawn stories… stories that are indirectly impacting the user.
Enabler story — since it indirectly impacts the user — has no user voice.
Example: system to check the balance so that the system would know how much money the customer has in the bank.
Steps to value: User and Enabler stories could form a story map to represent a certain workflow of activities needed to deliver a value. This chain of stories or chain of activities are called ‘ Steps to value’… a value stream if you will.
Linked and related stories: a user story and an enabler could just be related … both are linked by a relationship… both are needed to deliver a value. Example: the ‘system to check balance’ enabler story is linked to — and required by — the ‘withdraw money’ user story.
Caveat: if you can articulate the value of an enabler as a user story, do so! This way, it will help communicate to the business it’s relative importance. If you can’t then try to articulate the value of an enabler/technical work in the team iteration goal or team PI objective…in business terms…to help communicate to the business its relative importance.
Example: ‘system to check the account balance’ — an enabler story. A technical story.
An enabler or technical story could be articulated as a user story like this:
As a bank customer, I want the ATM system to check my balance first so that when I withdraw my money, I am withdrawing only the amount that is less than or equal to my account balance.
Or as part of the team iteration goal (has no user voice): create a bunch of widgets like ‘balance checker’ to support cash withdrawal.
Stop creating user stories like this: ‘as a developer…I want to … so that …’! Why? The developer is not the customer or the user, that’s why! User stories are intended for the customer or user… not for the developer. The same is true for ‘As a tester, I can… so that…’. Stop… the tester is not the user/customer — not the intended recipient of the value. Oh, don’t even try the ‘third person technique’: ‘as a developer, I want the user to have … so that the user will..’! Again, you, as a developer, are not the voice of the customer. You don’t get to speak for the user or customer. So… Just write it as an enabler… omit the user voice… and just blurt out what is needed to be done… and the value of it… the ‘why’!
A great way: using ‘User and Enabler’ stories is great ways to model products, systems and services. Enabler stories are great ways to articulate work behind the scenes … where the user interface or user experience does not change but the underlying components are.
Look beyond what you see — accounting and taxation: did you know that — by its nature of being a necessity to help create value… but not exposed directly to the user — enablers are categorized as capital expense? Whereas user stories — by its nature of being a necessity to directly create value… exposed directly to the users as they operate the system — are categorized as operating expense? Yup, OpEx and CapEx are essential to the enterprise’ accounting and taxation: reporting and filing. User and Enabler story types are key to categorizing the business’ operating expense (OpEx — for user story) and capital expense (CapEx — for enabler story) vis-a-vis the SAFe requirements model — see figure below.
The CapEx and OpEx math: at the story level: you may count all enabler stories that you have ‘accepted’ for the year , multiply that by your average points per story for the year… multiply that by the cost per story point for the year… the product gives you the capital expense (CapEx) for the year! Use the similar approach to calculate for the operating expense… only this time, you count user stories… that were deployed and released in production.
Bam! That’s another great way a ‘user and enabler’ story is used… this time to solve for accounting and taxation matters when SAFe Agile Requirements Model is used.