Have you ever written or been assigned a user story that sounds something like this:
As an admin, I want to approve photos before they go public so that I can make sure they are appropriate.
Role, feature, reason.
As a [role], I want to [feature], so that [reason].
Totally get it, it makes a lot of sense, and has worked for decades, right?
But what happens if we rewrite this as a Job Story (as popularized by Intercom)?
When [situation], I want to [motivation], so that [outcome].When someone submits a photo, I want to make sure it's appropriate before it goes public, so that we aren't offending the internet.
Or something to that effect :)
When someone submits a photo, I want to make sure it's appropriate, so that offensive material doesn't appear in our app.
The Job Story format is a modest change from traditional User Stories, and so shouldn't be overly offensive to any hardcore Agilists, but I've spent enough time in comments sections on this topic to know that it is. ¯\(ツ)/¯
What I like about this approach is that by emphasizing the situation, motivation, and outcome without explicitly defining a feature, our thinking can remain open to a number of different solutions rather than jumping right to, "we need a photo approval UI for admins".
Desired Outcome vs Requested Feature
Ryan Singer (of Basecamp) and Chris Spiek (of Rewired Group) have recently launched a short video series they call
. In ep 2, Ryan talks about the process Basecamp went through to solve one of their most common feature requests: a calendar.
A calendar is no small undertaking in any situation. In a team-based project management application with multiple active projects, task assignments (your own, your direct reports), permissions, and the inevitable request for integrations ... that turns in to a lot of software! And for a company famously committed to
, it's not much of a surprise that they released BC3 without a calendar view.
But they started hearing it from their customers