How to write user stories with impact

In an organization, demystifying the technical requirements along with business requirements is a challenging day-to-day grind, not only do you require strategic thinking, but logical and sound reasoning of expected outcomes, behaviours and high-level of prescription without going in too deep, in telling people what to do.

In building working software, gone are the days of practitioners talking about waterfall being the best use of product discovery and talking to anyone that says 'Waterfall can be planned in agile with sprints', you'll find mostly looks of sheer surprise and annoyance, depending on who you talk to, the more traditional companies that require the need of transparency of time, scope and budget in its the essence, rather than velocity, burndown, and increment are still around and as 'Product Owners' wearing the 'Change Agent' hat a catalyst for transition.

What makes agile work is the level of embrace it receives, but not all companies are ready to embrace a full-scaled agile concept, and when legs are running yet don't hit the ground, Agile as scary as legacy organizations deemed it to be, must be adopted in the Scrum team and many practitioners would agree with me, that you ain't running a scrum team if you're not running a scrum team, so let's explore how to introduce a user story concept as the first point of getting agility into rapid development.

Here's what has been successful with plenty of trial and error this is my tactical war chest in implementing Scrum.

Explain the need for Stories in Simon Sinek's Golden Circle method.

Use the INVEST method to assist you in communicating why it's important.

It's extremely useful, to communicate Bill Wake's INVEST acronym to help us remember the foundations of a great user story that drives impact.

Independent stories help us determine the incremental value without the interdependency of other tasks

for example, let's say you wanted to support creating a new user account using social media, and a user has a choice of becoming a member by connecting with their Facebook or their Google Gmail account'

Instead of making 1 big story with all three dependencies, you're going to break them down into 3 independent stories;

Feature

Sign-up with Facebook

'As a user, I want to be able to sign-up with Facebook, so that I can have my profile on all of my devices'   

Acceptance Criteria

'Given I'm a new user on the landing page, I see a pop-up that asks me to sign up, then I see a button to let me 'Login using facebook' button, when I press the 'Login using Facebook' button I can login using my Facebook Credentials to my profile page. 

Feature

Sign-up with Gmail

'As a user, I want to be able to sign-up with my Gmail, so that I can have my profile on all of my devices'   

Acceptance Criteria

'Given I'm a new user on the landing page, I see a pop-up that asks me to sign up, then I see a button to let me 'Login using my Gmail' button, when I press the 'Login using my Gmail' button I am prompted by my Gmail service, to login using my Gmail credentails, then it takes me to my new account and the application shows that I'm now logged in' 

Negotiable stories are not a detailed contract and are brief

A simple way to look at Stories

Valuable, a story should provide value to the customer in this case, we want the customer to have a lower barrier of entry and ease to connect their account in order to sync their devices, for convenience.

In addition, we can also create value statements of why we are building the feature and how can it help our business, in this case, utilizing Facebook data will know more about our users, and utilizing email log-in can help with email marketing.

Each feature has its own uses that are tactical for business and every feature aligns with a strategic output.

Estimateable, a story should be able to be estimated by a Dev!

If your Engineers are raising their hand and saying they cannot estimate a feature, it's down to;

Is the story too big to size? 

It's not often the case that a developer is not sizing their stories, due to domain knowledge and or technical snuff, but if it is, raise the flag to your engineering leads and your scrum master to assist with the compatibility of the task.

Testable, can we test it?

Stories should be ideally testable and this is where your Acceptance Criteria can come in, some PO's like to use expected behaviors and in addition, can include the Won't haves, to address any exceptions or edge-cases, but relatively keeping it to a minimal.

Pro-Tip: Link your stories together, the features in Jira assist with "Linking relevant stories" is helpful, it provides transparency when needed in your backlog and helps to assist QA and others get full context if they want to.