how to write a good user story

1. 🤔 WHAT IS A USER STORY?

PRODUCT STRATEGY

How to Write a Good User Story: with Examples & Templates

Published: May 2, 2022

12 min read

Andrii Bondarenko

Content Team Lead @ Stormotion

In this article, you'll learn:

🤔 What is a User Story?

👍 what are the benefits of creating user stories, 📝 how to write user stories: our workflow, 💡 conclusion.

We at Stormotion love Stories. As an Agile-driven Team we actively use them to get a better understanding of what benefits our clients’ products deliver to their end users. They also drive collaboration and creativity, pushing us to non-trivial development solutions.

So today we’re going to share our knowledge and experience on this matter to help you improve your Story-writing skills. Enjoy!

User Stories are one of the core elements of the Agile methodology. However, they’re often jumbled with software requirements which isn’t true. So what is a User Story?

User Story is a small (actually, the smallest) piece of work that represents some value to an end user and can be delivered during a sprint.

In projects like mental health app development , the main aim is to put end users at the center of the conversation, capturing product functionality from their perspective. Thus, developers get a better understanding of what, for whom and why they’re building.

Wow, it’s been said a lot about User Stories. But why are they so important to Agile teams?

If you were ever involved in working with Agile frameworks, you already know that both Scrum and Kanban teams greatly benefit from writing User Stories.

We’re getting to the most thrilling part of our article. However, before we share our step-by-step instruction on writing a User Story, it’s crucial to figure out 2 essential questions: who and when makes them.

Who is responsible for creating a User Story?

As a rule of thumb, Stories are mainly written by Product Owners since it’s their responsibility to keep the Backlog filled with tasks. Yet, don’t forget that Agile is based on communications and opinions exchange between experts. So...

It doesn’t necessarily mean that they should be written only by a Product Owner. The more people join the conversation, the better.

At Stormotion, Stories are written by all team members who are related to the business-side of the project (sales managers, marketers, a product owner etc.), since it let us look at the future app from the perspective of any potential kind of user. The responsibility of the Product Owner in this case is to confirm that they’re match the INVEST criteria.

So that’s how to write User Stories in a nutshell. Our Stormotion Squad also uses the following tips when working on this task:

• Start with Epics. It’s usually easier to move from more complex tasks to more specific ones so try writing Epics and then split them into Stories.
• Listen to feedback. Sometimes you don’t need to guess Stories - ask your real end users for feedback and use their ideas as a source of inspiration.
• Don’t introduce details too early. It’s better to hold the brainstorming session before each sprint to discuss how to implement planned Stories.

User Stories are an essential element of the Agile approach that can bring many benefits to your project. However, it’s important to write them correctly which requires some time and skills.

Examples of good User Stories meet the INVEST criteria, meaning that they’re:

• I ndependent
• N egotiable

The common User Stories template includes the user, the action and the value (or the benefit) and typically looks like this:

As a [type of user], I want [an action] so that [a reason/a value]

User Stories can help you to constantly improve the value of your product, estimate development efforts in an appropriate way and prioritize feature development during the MVP and post-MVP stages.

Boost Your App Development With Us!

Was it helpful?

About author

Content-Marketing Maestro @ Stormotion. Crafting compelling stories for a brighter world.

Andrii Bo...

Author page

Stormotion's ChatGPT Journey

10 MIN READ

Top 5 Best Practices for Integrating ChatGPT in Your App

DEVELOPMENT

11 MIN READ

How to Build SaaS App Like Spotify

How can we help you?

Please tell us about your project

By sending this form I confirm that I have read and accept the Privacy Policy

Our clients say

They were a delight to work with. And they delivered the product we wanted. Stormotion fostered an enjoyable work atmosphere and focused on delivering a bug-free solution.

David Lesser, CEO

How to Write a User Story in Software Development that Focuses on the User

By Kate Eby | July 17, 2018 (updated November 20, 2023)

• Share on Facebook
• Share on LinkedIn

Link copied

A risk that comes with software development is that end users find little value in the functionality you develop. But, there is a simple answer to that quandary: writing effective user stories before beginning development. The practical application of user stories provides a framework to identify user value by prompting conversations throughout the lifecycle of the software build. This article will explore what a user story is and isn't, how to write an effective story, and the importance of conversation over task lists.

Empathy is key to user story development process, and while many would argue it is easier to develop a list of requirements, the benefits of taking the time to understand your user is essential to delivering real value.

What a User Story Is and Is Not

User stories emerged as a result of Extreme Programming (XP) , Kanban , and Scrum’s need to break down projects into smaller, incremental segments for sprints and iterations. They differ from use cases in that they focus on the smallest possible unit of work. Use cases, originally introduced by Ivar Jacobson, may be made up of several stories based on a common theme. The stories themselves are simple narratives outlining a single expectation or user goal. You can breakdown the creation of a user story into three stages:

• Describe the need.
• Plan the iteration.
• Implement and test the story’s completion.

At each stage, the user story can be refined to perfection.

User stories do not contain a requirements list or coding instructions, but will be associated with acceptance criteria or tests. The goal of a user story isn’t to focus on how to build, however. Instead, the focus is on who wants the feature, what it will do, and why it is important. Stories bring a human element to features that eventually make up the backlog activity to-do list.

Why Are User Stories Important?

More than just a list of features, stories bring the user into the conversation. User stories provide context to software development by focusing on the value the user will experience. This people-first process mutes the language of Agile , allowing non-developers to collaborate and participate in conversations.   

User stories help facilitate constant dialog throughout the IT development project to aid in areas such as iteration/ sprint planning and prioritizing the backlog for a release. By contrast, traditional Waterfall development embraces dialog at the beginning and the end of the development process.

In his book User Stories Applied for Agile Software , Mike Cohn of Mountain Goat Software says, “We make decisions based on the information we have at hand, and we do it often. Rather than making one all-encompassing set of decisions at the outset of a project, we spread the decision-making across the duration of the project. To do this, we make sure we have a process that gets us information as early and often as possible. And this is where user stories come in.”

Who Writes the User Story?

Product owners, stakeholders, product managers, and other business team members participate in writing user stories. Many will say, however, that who writes them is less important than who participates in the discussions and conversations that bring the stories to life. Start by identifying who will use the feature (the persona ), which can be as detailed as needed. The user can be defined in terms of function or job description, such as student, frequent flyer, or marketing manager.

Having a strong understanding of the end user limits developer biases or assumptions. If the users are available, they can participate, but often the team has designers, managers, writers, and others who act as customer proxies. Participants may vary based on the usage of the user story. For example:

• User Story Creation: Participants may include customers, product management, engineering, and other stakeholders such as HR, finance, and sales.
• User Story Maintenance: Participants include product management or a product owner.
• User Story Application and Usage: Participants include engineers/developers, technical writers, and quality assurance testers.

How to Write Effective User Stories

User stories are simple, one-line benefits statements of a valuable function. Prior to writing the user story, conduct user surveys and interviews to query the user about needed functionality. Start by writing a customer journey, stated in incremental stories, on 3x5-inch cards or Post-it notes. These cards can be put immediately into production or provide context for the backlog.

In the case of user story mapping , you can display Post-it notes along a conference room wall so the entire team can see it and work on long-range planning.

There are a few techniques you can use to help write the stories you need. A common technique is the Role-Feature-Reason or Benefit (RGB) structure that you construct by filling in the blanks of this sentence:

• As a (user/persona/customer), I want to (do something) so that I will (receive a benefit).

Adding to the RGB question is a method pioneered by Ron Jeffries which highlights his “three C approach:”

• Card: Write the answer to the RGB (described above) on the card.
• Conversation: The limited detail on the card is the basis of a promise fulfilled by the second C. During this phase, the team discusses the details and establishes a definition of “done.”
• Confirmation: This is the result of feedback that determines the test or acceptance criteria. This acceptance criterion is often written on the back of the card and is used as the initial checklist during future meetings to determine completion.

First introduced in an article by Bill Wake in 2003 and popularized by Mike Cohn’s book, User Stories Applied for Agile Software Development , the acronym INVEST is a method to evaluate user stories. INVEST criteria is as follows:   

• Independence to develop in any sequence.
• Ability to Negotiate the extent of the story to develop.
• Provides Value to the user or business.  
• Can be Estimated for completion.
• Is Small enough to design, code, and test in a single iteration.
• And finally, can be Tested .

Writing user stories that follow the RGB and three Cs methods are good starting points. Evaluating for effectiveness against INVEST goals keeps stories small, functional, and testable.

Bennett Lauber, Chief Experience Officer with  The Usability People, LLC , makes the following suggestions for someone preparing to write their first user story: “Make sure you do some research on your users and create personas. This will help the development team have empathy with the user.”

Agile User Story Template

Ready to write a user story? Download a free template to help you clearly define the feature from the end-user’s perspective. The template includes space for the type of user, what they want, and why they want it. By creating these short, one-sentence user stories, the development team can develop code that will satisfy the user story requirements. Find other useful Agile templates that you can download here .

Download Agile User Story Template

Excel | Smartsheet

How to Write a Test Case from a User Story

A user story provides the guidance for developing tests or acceptance criteria. This checklist helps developers determine when the feature is done. As with all elements of user stories, the acceptance criteria is also written from the standpoint of the user. The test or acceptance criteria outlines the elements needed to successfully perform the required function.

This criteria should include the following:

• The intended functional and non-functional requirements
• Negative scenarios of the functionality
• Performance guidelines
• Proper user workflow
• Impact to other features
• User experience

Thomas Stiehm, CTO at  Coveros , writes test cases using Gherkin Language. “This is the given, when, then (GWT) format,” he says. “I use test automation in Cucumber and that consumes Gherkin for automated testing. In addition, involving an experienced tester helps create better stories. They can ask important functionality questions while the story is being developed, which in turn results in more usable functionality.”

Let’s use a conference registration as an example test case: A user submits a form that includes their contact information, they choose a payment option, and a confirmation is displayed on screen and sent via email. These become part of the acceptance list. The test case also considers the ease and flow of the user experience (UX). Like the user story itself, the amount of detail tested reflects only what is necessary to ensure the feature delivers value.

Hernan Santiesteban, of  Great Lakes Web , shares his advice. “One of the best ways to write a test case is to use the given, when, then template, which establishes test conditions, user actions, and expected outcome. For example: given an administrative user signs in successfully, when the admin opens the user dashboard, then the admin will be presented with user management functions.”

Benefits of Writing Strong User Stories

To some product managers and development team member, writing user stories instead of requirements lists can feel like adding more steps to the overall Agile process. However, a key benefit of user stories is that they are collaboration-dependent and keep everyone informed and on the same page. Things can change during the development processes through discovery and stakeholder feedback — as a result, user stories can change or adapt to these circumstances.

Some of the most common benefits include the following:

• Demonstrate progress quickly by breaking down the big picture into smaller projects.
• Motivate the team and keep the project moving forward with quick successes.
• Put the end-users first and thereby foster greater user acceptance and satisfaction.
• Prioritize high-value features.
• Provide the platform to have collaborative conversations that allow for creative solution planning.
• Encourage high levels of cooperation that keep the team focused on outcomes that, in turn, create better overall products.

How to Write a Good User Story

It seems counterintuitive that the development of large software initiatives enjoys success and efficiency by going old school.  Simple 3x5 cards of varying colors and a permanent marker provide the humble basis for authoring user stories that bring context to an Agile development process. The small cards encourage basic benefits-driven descriptions that are discovered through team collaboration.

All user stories are unique and they should be complemented by story maps, diagrams, storyboards, and mockups, but below are a few best practices that can help you write an effective user story:

• Know Your User: Define and understand your user persona(s).
• Include All Stakeholders: Be sure to include all relevant stakeholders in the user story writing process. The testing team may even be able to refine the story.
• Focus on the User: Discussions and conversations from the perspective of the user provide context and a definition of what constitutes “done.”  
• Keep It Short and Simple: Describe only one piece of functionality in each user story. If a story is too big to be developed in a short period of time, break it down into smaller increments or create specific conditions can be added that limit the function. A good rule of thumb is that a user story should be small enough that the development team can complete it in one iteration.
• Discuss and Collaborate: Discussions on project size, minimum viable product (MVP), who will use it, what it will do, and why it brings value all aid in decisions on inclusion and scope.
• Avoid Technical Details: Don’t write technical tasks or “how to build” statements into the user stories as they may prevent creativity and collaboration. Technical details will come later in the process and be incorporated by developers, testers, and systems architects. A template can help guide away from technical details.
• Focus on the 3 Ws:  Who will use it, what it is, and why it is important.
• Encourage Visualization: Use whatever methods (drawings, story and impact mapping, storyboards, and mockups or prototypes) are appropriate to visualize the finished product. .
• Clarify the Value and Benefit: Be sure the purpose of the story is clear, the urgency is noted, and the story is complete.

Challenges and Common Pitfalls of Writing User Stories

A user story answers questions such as who will use the feature, what the feature will do, and why the feature is important. The story’s details provide the business context, user value, and drive team discussions. A common challenge when writing user stories is ensuring that the story is comprehensive enough to articulate value, but simple enough to deliver in a short period of time, such as a sprint (which is generally between one and four weeks). The story should not contain technical details of how it will be built or coding instructions. These details are not needed at this point of development.

If a story is too big or too broad, it can be broken down into small parts.

Here is a good example:  

• As a bank customer, I want to be able to see my balance, so that I can plan bill payments.

It may be tempting to add more detail or other functions, but that will create an unwieldy narrative. This kind of story would look something like this:

• As a sales manager, I want to get my forecasting, sales, and personnel reports, so I can set my budget for an entire year.

This example has multiple components (generating individual reports: forecasting, sales, and personnel) that should be broken down into several smaller user stories.

In addition, be sure to include acceptance criteria, which identify what constitutes "done.” As noted above, acceptance criteria are often written as a checklist on the back of the user story card.

Additional challenges when writing acceptance criteria include the following:

• The natural tendency to focus on how to build. However, leaving this technical detail out of the dialogue drives more meaningful conversations that lead to creative solutions, and also allows the inclusion of users and non-technical team members in the discussions.
• Dialog and conversations can be time consuming and are often forgotten, which limits the positive impact of user stories.
• Lack of data or a real understanding of the user or persona endangers the acceptance of functionality when put in the hands of the end user.
• Limiting stories to the smallest increment is not easy, but too much detail makes the user story unwieldy.
• Leaving out essential information, such as acceptance criteria or customer benefits, can leave questions unanswered during the development process.

Mike Cohn’s book User Stories Applied for Agile Software identifies the core problem in software development with this simple observation: “Software requirements is a communication problem.”

The technical language associated with software development and Agile methodologies can be a hindrance for many. Throughout the development process, writing user stories incorporates open dialog and conversations by breaking tasks down to keep momentum flowing, and providing strong Definitions of Done. Building software is a large-scale, time-consuming process with many stakeholders and high expectations. However, by following some simple guidelines and some old-fashioned techniques, the intricacies of building software become more visible to an entire team and, in the end, more doable. 

Master Writing User Stories with Smartsheet for Software Development

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time.  Try Smartsheet for free, today.

Discover why over 90% of Fortune 100 companies trust Smartsheet to get work done.

How to Write a Good User Story: with Examples & Templates

Writing requirements for a software project without a structure is a complete nightmare.

Writing requirements for a software project without a structure is a complete nightmare. Anyone who's worked on the development side of building a digital product knows that the biggest challenge isn't building the thing; it's knowing what to build.

Like everything else in software development , there's a scientific, systematic solution to this problem; the user story. A user story is a syntax of defining a requirement that's become the incumbent in software development because it both the business and developers understand what's required.

I've probably written more than 10,000 user stories. Still, whenever I take a break for a few months, I find myself browsing Google looking for examples of stories to see if I can strike up some inspiration of how to handle the trickier stuff (like authentication, project setup, design tasks , etc).

Every time I go looking, I end up on Reddit where the answers usually follow the theme of "no one would share actual user stories because they're legally protected" - which isn't true. It's just that user stories are boring, and no one has bothered to make Google index an article actually dedicated to story examples... until now :).

I'm sharing some examples of actual stories I've written recently, along with the behaviour-driven-development acceptance criteria my team uses to make sure that everyone understands the requirements and acts as a baseline for our automated testing.

Enjoying this post? Get more delivered to your inbox!

Enter your email to get a monthly round up of technology tips and news.

What is a user story? Our definition

A user story is a vehicle for describing a system feature that follows a particular syntax. Even though it's technically possible to write a story without following this syntax, it wouldn't really be a proper user story.

Here's the user story syntax:

As some kind of user, I want to perform an action, so I can achieve an outcome.

The idea behind this formula is to answer the biggest questions that developers have when they start building the feature.

Which user are we working with? Is it an administrator, a user with restricted permissions, or someone who shouldn't even have access to the system ?

What does the user want to do? From the user's perspective, what are they trying to do? The important distinction here is the question isn't asking, "how should this feature work". Requirements should be agnostic of implementation suggestions.

Why do they want this? Sometimes it's hard to understand how a feature should work simply by knowing what the user wants to do. Having the additional context to understand why they want to do something can let developers create a better-fitting solution.

Pros of using stories

User stories can feel tedious to write out, but they bring tangible benefits to the organisation and management of a software project .

Remove assumption

The biggest problems with application development projects usually come from making assumptions. Assumptions aren't limited to how the developer implements a feature ; they're also made by the product owner (or client) on what's feasible.

Define intent

Without including the "so I can achieve an outcome" part of a user story, it's just a vague request that may not be the best way to achieve the outcome. Knowing the intention of a requirement helps get the product owner and development team on the same page.

Standardised requirements

Without a structure to stick to, requirements tend to take the easiest and sloppiest form. It's rarely consistent or detailed enough to figure out what needs to be done. Dealing with a large number of requirements that don't follow the same structure or approach is an absolute nightmare.

Provides stakeholders with a way to communicate

Stakeholders who are working with a development team rarely know how to think through their requirements fully or communicate them eloquently. User stories give them a concrete approach for explaining what they want.

Cons of user stories

User stories on their own don't really have "cons" or "disadvantages". The problems come from their implementation.

They're easy to write poorly

It's easy to accidentally write a user story the wrong way, so it doesn't communicate the business's need. For example:

As a user, I want to implement a form plugin, So I can have a working form.

From a developer's perspective, this doesn't get you any closer to understanding what the customer wants . The requirement is coloured with technical implementation details. If the best possible solution isn't to use a form then the development team can only achieve this requirement through a sub-optimal implementation.

Customers often find themselves writing user stories, especially if they're going to market to get developer quotes. Without some understanding and practice, the requirements end up needing to be rewritten down the line.

The format can feel repetitious and tedious

A big application can require hundreds of user stories. If there are only one or two user types, then starting every single story with "As a user..." can feel

Stories aren't complete without additional detail

User stories are a conversation placeholder and aren't intended to have all the details required for a developer to start building a new feature. That part needs to be handled during a sprint planning session or technical review.

To get the most out of our user stories, there needs to be well-defined conditions for completion and examples of how the story should work. This is where acceptance criteria and behaviour-driven development scenarios come in handy.

What makes a good user story?

A good user story doesn't necessarily need to follow the regular syntax, despite what a lot of die-hard agile project managers will argue.

To be useful and complete, a good user story need to:

• Covers a description of the feature to be built
• Avoids any description of how the feature should be built (i.e. technology )
• Explains the value to the end user
• Has an outcome that can be measured and achieved
• They're testable

A lot of teams, including ours, will start writing user stories in a slightly different format. However they're written, the story always needs to inform both parties of what's required and have a clear way of being achieved.

Behaviour-driven development scenarios

Before we get to the user story examples, it's worth talking through the other methodology we use to expand on the information available for the developers. User stories by design, are supposed to be concise and indicative. The developers and designers implementing the story will have plenty of questions that need to be answered.

Behaviour-driven development is an approach of documenting requirements with examples. It follows a similar syntax to user stories:

GIVEN some condition has been achieved WHEN a trigger event happens THEN a result will be achieved

The idea is to document a few primary examples of how a feature (or user story) will be used. Providing actual examples not only acts as a great way to get everyone agreeing on how it should work, it also makes the product team think through the edge cases and creates tests that need to be passed for the feature to be considered complete.

Agile user stories examples

Finally, on to the actual examples. I've anonymised and sanitised these stories and scenarios a little to avoid making any of our clients upset.

These stories would typically have a handful of acceptance criteria too for peripheral behaviours like confirmation or validation messaging. To avoid making them too hard to read through, I've left these out.

Feature: Marking invoices complete.

Story: As an administrator, I want to mark a job as invoiced, so it can be recorded and reconciled with accounting.

Scenario 1: A job is completed and marked as invoiced

GIVEN I'm logged in as an administrator AND I've completed a job WHEN I mark the job as invoiced THEN the UI will show the job as invoiced AND the job status will change to invoiced

Scenario 2: A job is not complete and marked as invoiced

GIVEN I'm logged in as an administrator AND a job has outstanding tasks WHEN I mark the job as invoiced THEN I will receive an error message that says, "Job can't be invoiced until all tasks are completed"

Feature: Carpenter marks installation as complete

Story: As a carpenter, when I've finished my installation, I want to mark it complete so everyone else on the team knows it's done.

Scenario 1: The carpenter marks the job as complete, and job status changes

GIVEN I'm logged in as a carpenter AND I've finished an installation WHEN I mark the job as complete THEN its status will change to "installed"

Scenario 2: An administrator wants to know if a job has been installed yet

GIVEN I'm logged in as an administrator AND I want to know if a job has been installed WHEN I open the job THEN I can see it's status is "installed"

Feature: Staff unavailability

Story: As an administrator, I want to see a list of upcoming days when the staff are unavailable, so I can resource and plan efficiently

Scenario 1: An administrator wants to check who took holidays last month

GIVEN I'm logged in as an administrator WHEN I view past staff unavailability THEN I can see a list of all staff holidays that are in the past

Scenario 2: An administrator wants to check if a staff member has any upcoming holidays

GIVEN I'm logged in as an administrator WHEN I view upcoming staff unavailability THEN I can see if a staff member has an upcoming holiday registered

Feature: Calendar rolling date

Story: As an administrator, I want to easily scroll up and down the calendar to see past and future dates, so I can plan my team's workload efficiently

Scenario 1: An administrator wants to schedule a job 4 weeks in the future

GIVEN I'm logged in as an administrator AND I want to schedule a job in 4 weeks time WHEN I scroll down the calendar THEN new weeks will display

Scenrio 2: An administrator wants to check how many jobs were done last month

GIVEN I'm logged in as an administrator AND I want to see what work was completed last month WHEN I scroll up on the calendar THEN I can see all the jobs that were scheduled and completed

Feature: Discourse Single Sign On

Story: As a user, I want to sign into Discourse using the same credentials I use for the app, so I can see my forum posts and comment history

Scenario 1: A user wants to add a comment on the integrated Discourse forum

GIVEN I'm logged in as a user AND I open the integrated Discourse forum WHEN I leave a comment THEN I will be successful without having to sign up for a new account

Scenario 2 : A user wants to view their forum post history through Discourse

GIVEN I have an active application user account AND I've left comments on the forum in the past WHEN I log into Discourse THEN I can use the same credentials I use for the application AND I can see my forum comment history

This is a decent cross-section of user stories and scenarios to get you inspiration moving.

How to Write User Stories: Our Workflow

The last thing to explain is our full process for building user stories. Achieving a full coverage of stories can be tricky and it's easy to miss things at the start of the project.

At the start of every project, we run a Product Roadmapping session with our clients , consisting of a handful of 2-hour meetings. One of the goals of the sessions is to understand and document the major user workflows. A workflow is a user's steps to achieve their goal.

Because workflows are less granular than stories, capturing them in totality is easier. Once you've got all the workflows, then you can move forward to breaking the workflow into the individual stories. Then the stories are decomposed into scenarios and acceptance criteria!

Wrapping up

Hopefully, this breakdown of how we write user stories, along with a handful of actual examples, has helped you on your journey. If you have questions, please leave a comment below, and we'll get back to you in a few business days.

Tim Davidson

Tim is the face of the company. When you want to kick off a new project, or an update on your existing project, Tim is your man!

Read more on the subject

Customer Experience (CX) - Why It Pays To Invest In CX

Customer experience refers to your business's customers' perception of dealing with you.

Is Mobile First Always The Best Approach?

Mobile-first design is a term thrown around a lot in the UI and web design industries, but there often need to be more clarity about what it is and why you should use it.

Digital Product Design Process

Digital products have the unique ability to scale to global proportions with relatively few fixed costs.

Don’t miss out on the latest stories!

Sign up for my newsletter to receive the latest news from the blog, you’ll get pinged every few months with a digest from the tech world.