loading...

re: Enough with the User Stories already! VIEW POST

FULL DISCUSSION
 

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

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.

Code of Conduct Report abuse