User stories. But why?

 

User stories. But why?

Since the dawn of humankind, we have listened to and shared tales with one another , the best ones being scary, creepy bump in the night tales, which most definitely are true. Whether to teach or to entertain, storytelling is intrinsic to our mental wiring. Sure, we can produce manuals and list instructions but nothing cements in our lizard brains, quite like a tale well told. 

Some of you maybe old enough to remember project charters, heck some of you may have spent months writing them. For it to then be passed to a higher-up stakeholder to sign it off. And what does our higher-up stakeholder do? Ask a junior team member to read it and let them know if it’s ok to sign it off. For those of you haven’t experienced this, we actually got paid to do this merry little dance 💃.
The pitfalls are obvious (if they are not, comment below and we can tell that story at our next campfire gathering!🔥). I won’t bore you with them here, instead let’s discuss how to avoid said pitfalls and reduce risk. 

Keep It Simple, Stupid 💋

Product monsters are always tempted to provide more and more detail, from "Once upon a time, in a land far, far away..." to so much context we risk losing our audience. For our user stories we can strip the excess thrills and chills right back...

Stick to a standard template: 

As a [type of user], 

I want [an action], 

so that [a benefit/a value]. 

For example:

 "As a frequent traveler, I want to receive flight delay notifications so that I can adjust my plans accordingly." 

Maybe not the most engrossing story ever told but in a single sentence, we get it! Always adopt the user’s perspective. 

👱Utilise user personas:

The above example would be even better if we would refer to “Fred, our frequent traveller, wants to receive…” If you have done your persona work, you will know all about Fred and why this matters so much to him and this creates a real knowledge shortcut for your team and collaborators. 

👭Engage in Collaborative Discussions: 

Involve cross-functional teams—including developers, designers, and stakeholders—in conversations about user stories. Just like sitting around a campfire and sharing scary stories while toasting marshmallows. Except this time, you are removing fear, and risks are getting toasted as your storytelling shines a light in all the dark corners. This collaboration fosters a shared understanding of user needs and promotes diverse perspectives. 

💚Define Clear Acceptance Criteria: 

Establish specific conditions that determine when a story is complete. Clear acceptance criteria ensure that the developed feature aligns with user expectations and requirements. More simply put, define what "done" looks like, in this case we would start with:

"Fred doesn't have to log in to his his frequent flyer account as he receives a push notification telling him of a delay. 

Fred will continue to receive updates if the information changes further" 

and because you have collaborated with your team you will be able to provide technical definitions of what done looks like, which will guide developers. 

👷Break Down Stories into Manageable Tasks: 

Divide larger user stories into smaller, actionable tasks that can be completed quickly. This approach maintains focus on user needs while ensuring steady progress. The effort you put in during your campfire conversations and creation of done definitions will really feed in to this part of the work. You may have a team which would like this done up front as much as possible, or you may have more tenured team who prefer to slice, do, slice, do - one chunk at a time. Either is fine - providing that it works. You can experiment with your team, story telling, and task breakdown to find your team's optimal approach. 

👍Prioritise Based on User Value: 

Assess and rank user stories by the value they deliver to the user. Prioritising in this manner ensures that the most impactful features are developed first. 

🥳Iterate and Refine Regularly:

As with your product or team backlog, continuously revisit and update user stories based on developer feedback and changing requirements. Regular refinement keeps the development process smooth and makes those campfire stories a little less scary! Which brings us to the end of today's campfire tale. Not as scary as I normally I like my stories, but then I don't won't want to be scared at work! So my little product fiends 💀, until the next bump in the night...