Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Very much enjoyed reading the article. And at some point definitely agree with the idea we should get our language sorted. I'm experiencing exactly the same scenario as pointed out in the "Twitter" / social media example here, once in a while, when different stake holders argue about how broad or generic a given user story should be. For that example: Is "I want to be able to log in using Twitter credentials" an implementation detail? Is it a high level business "user story"? As far as I am concerned, it depends. It could be both, and both could be very well valid. Using the impact map approach could help getting such things sorted, but what helped in my environment pretty much in such situations is a slow and careful process of balancing different stakeholders and dev teams in order to find a "common ground" understanding of things, a shared level of abstraction that works reasonably well for most (best of course: all) people involved with the process.
Fred is a software jack of all trades, having worked over the last 24 years at every stage of the SDLC and has authored [two books](https://www.amazon.co.uk/Fred-Heath/e/B08F3Q1H1M).
thanks for the feedback Kristian. IMO, "I want to be able to log in using Twitter credentials" sounds like it answers the question "What do I want to do with the system so I can achieve my Business Goal?" and is, therefore, a Capability.
However if the Business Goal is "Make system login easier so that I can attract more users", then you can say that the Capability is "able to log in using Social Account credentials" and "login with Twitter" answers the question "How do I deliver this capability?" i.e. a Feature
I find that the following help to distinguish a Capability from a Feature
Capability
Feature
Granularity
Coarse
Fine
Key Action
Enables
Allows
Key Question
What to do?
How to do it?
POV
An actor wants to do something
System offers a functionality
It's all about putting things in the right context and Impact Mapping is ideal for this.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very much enjoyed reading the article. And at some point definitely agree with the idea we should get our language sorted. I'm experiencing exactly the same scenario as pointed out in the "Twitter" / social media example here, once in a while, when different stake holders argue about how broad or generic a given user story should be. For that example: Is "I want to be able to log in using Twitter credentials" an implementation detail? Is it a high level business "user story"? As far as I am concerned, it depends. It could be both, and both could be very well valid. Using the impact map approach could help getting such things sorted, but what helped in my environment pretty much in such situations is a slow and careful process of balancing different stakeholders and dev teams in order to find a "common ground" understanding of things, a shared level of abstraction that works reasonably well for most (best of course: all) people involved with the process.
thanks for the feedback Kristian. IMO, "I want to be able to log in using Twitter credentials" sounds like it answers the question "What do I want to do with the system so I can achieve my Business Goal?" and is, therefore, a Capability.
However if the Business Goal is "Make system login easier so that I can attract more users", then you can say that the Capability is "able to log in using Social Account credentials" and "login with Twitter" answers the question "How do I deliver this capability?" i.e. a Feature
I find that the following help to distinguish a Capability from a Feature
It's all about putting things in the right context and Impact Mapping is ideal for this.