Step two: Now that we have a ‘pool of meanings’ regarding the feature and the activities, we now have a collective understanding of the pool of shared meanings… that is, hopefully, enough…to allow us to synthesize these into various stories… that, collectively, will deliver the value as intended to be delivered by the feature.
Story storming: the synthesis process uses the ‘story storming’ technic. Get your collaborators gather around and jot in — put in a post it note — as many stories as possible per activity or set of activities. Post it on the wall. No judgement. Then remove duplicates or put together similar stories. The result is a map of a series of stories that, together, deliver value to the user.
Important: remember to apply this very important story type classification:
Stories that directly impact the customer are ‘user’ stories. It has the user voice. Example: ‘As a merchant, I want … so that …’. The merchant is the user.
Stories that indirectly impact the customer are ‘enabler’ stories. It does NOT have the user voice… just blurt out the intent of the story! Example: ‘create two fields in the database’. I see a lot of mistakes like: ‘as a developer, I want to create two fields in the database so that… ‘. The developer is not the user! Avoid this mistake.
Always find the user (i.e. customer/persona) and express your story from the user’s standpoint and direct usage. If you cannot find the user, then the story is an enabler type, else it’s a user type.
‘Customer centricity’ is very important in SAFe 5.0. Knowing the difference between ‘user’ and ‘enabler’ types is paramount. This applies to features (there is business feature and enabler feature). This applies to capabilities (there is business capability and enabler capability). This applies to Epic (there is business epic and enabler epic). Everything scales up in SAFe!
