Delivering Business Value Through Agile Methodologies

Defining User Stories

Title: <value> as a <role>
Description: As a <role> I want to <value> in order to <business value>

• User stories determine scope (the what)
• Think from the stakeholder’s perspective
• Write in a way that all stakeholders understand

<Role>

• Mention stakeholders by name or team when necessary
• Consider defining Personas for your product(s)
  • Fictional – but accurately represent a product user
  • Add enough relevant fiction to humanize the persona, but just enough

<Value>

• Use the customer’s DSL (Domain Specific Language)
• Avoid relative words (fast, big, bright, loud)
• Be concise
• Remove noise (distractions & fluff)
• Communicate important and relevant information

<Business value>

• Conversation is driven from the highest level of business value
• The business value will eventually be realized through a User Interface of some sort but this is typically not the focal point of the conversation.
• The user is not purvey to HOW and WHY a business chooses to deliver features

Pop the why stack

There are exactly 3 reasons to create a user story:

1. Increase revenue
2. Protect existing revenue
3. Decrease cost

One of these three reasons will be obscured in the <value> section of the user story description. De-obfuscate the value by asking why (popping the why stack) and de-prioritize user stories when you cannot determine the value.

Defining Scenarios

• Communicate the WHAT, not HOW or WHY
• Use Gherkin syntax (GIVEN-WHEN-THEN)
• Describe the behaviors of the feature NOT reproduction steps
• Begin with the THEN when you don’t know where to start
• Remove the notion that you are creating a web, mobile or desktop application (HOW)
  • We are creating business value