Digital Capabilities
This is a continued blog post series. You can find the first post here.
In the ADDR process, digital capabilities are used to create alignment between business, customers, and technology to avoid negative consequences and anti patterns listed in chapter 2.
Chapter 3 goes right into the first step of the ADDR process. Identifying digital capabilities.
A digital capability is an implementation or automation of a business problem or a customer problem.
Job Stories or Job To Be Done (JTBD)
Examples of digital capabilities are shown. For example.
“Manage projects from start to finish”
which are mapped to an example API URL.
POST /projects
The JTBD concept helps us focus on a tangible problem a user needs to get addressed.
So there is a focus on the customer need. The digital capability should reduce anxiety involved for the user.
James present the idea of a job story for which he found inspiration in the following article
replacing the user story with the job story
“Job stories seek to identify the problems that customers have and the eventual outcome they wish to achieve. Jobs are identified that will solve these problems. APIs will offer digital capabilities that will power these JTBD to produce the desired outcome”.
My Comments:
This is like taken out of Jeff Patton’s book “User Story mapping”. Patton describes a minimal viable product as the minimal product that satisfies its desired outcome.
It sounds like James present a digital capability as a single operation that solves a concrete tangible problem. I think this is very concrete and useful. Originally I would consider a digital or business capability to be bigger than a single operation. Like a bounded context in Domain Driven Design. Or a cohesive set of services or operations that together serve as a capability.
But maybe we can solve this by talking about the big and the small capabilities. I Think both are useful.
It turns out that later chapters clarifies this.
The Job Story Format
Job stories are composed of three components using the “When, I want to, so I can” format:
When: The triggering event to establish causality is the situation or reason why the customer desires the outcome. Triggering events are key indicators for when an API will be used.
I want to: The capability is what the customer has identified as the action that needs to be taken. The capability identifies the important role that the API will play to deliver the desired outcome. It is also used to deconstruct the operations that the API will deliver.
So I can: The outcome is the desired end state. It is the result of applying the capability when the triggering event occurs. The outcome drives the acceptance criteria for the API design
Why could this be more effective than the user story format?
And I understand why this indeed makes sense.
Rather than focusing on the user role we focus on the trigger. When and why do we have a problem we want to solve?
Techniques for capturing job stories
The book mentions spread sheets, documents and markdown among other things.
There is a link to examples on github.
Below you can se what the markdown samples look like.
Challenges when doing job stories
The chapter also explain some good variants on how to capture the job stories given different starting conditions. As well as listing some standard challenges.
These are some of the things you need to get the book to read more about 🙂
Summary
Chapter 3 is about the first step of the alignment part. Identifying digital capabilities. The book suggest a variant of ‘user stories’, called ‘job stories’ where we don’t focus on the user role but on the triggering action! When is it, some wants to do something to achieve an outcome.
I Definitely want to play with the job story format. The fact that you focus on the causal state that triggers the job story made me think about event modeling, where we graphically show a user journey together with events, command and read models in the system. It feels like we could somehow turn the job stories into a user journey similar to an event model.
Sometimes it can be hard to convince people that its worth wile to spend time doing this upfront alignment work. The book is a good resource to get your arguments sharp.
