You're not alone if your user stories are sitting "In Progress" for most of the sprint and the delivery isn't happening the way you wanted it to be.

This is a common problem being faced by those who are passionate about building great products as well as for those who are handed an opportunity. Here is a jab at outlining what may look like a same-same-but-different style of writing user stories that is focused on increasing the speed of one thing and one thing only - delivery!

What are User Stories?

Say you're building a software that allows users to exchange messages using a website. If we go by the definition, a user story is an end goal - the smallest unit of work expressed from the software users perspective, hence a basic story for your messaging software may be "AS A customer I WANT to do/access something SO THAT I can get value".

Above is a simple representation of how you can break a software (like our messaging platform) in to Themes (say User Acquisition, Messaging) into Epics (say Authentication, Send Message), and Epics into Stories (say Sign Up Page, Validate Message) and then finally Stories into Tasks (say Email Sign Up, Detect Links in Message etc.). I personally hate using tasks and believe it's wiser to keep stories small, but that's me and you don't necessarily have to do what I do.

3C's of a User Stories

3C's is a great framework to remember while creating or validating user stories. Here is my version of the 3C's.

1. Card essentially is either a physical card the story is printed on or a card in the software having a unique number to it.
2. Conversation is the "AS A Customer I WANT a sign up page SO THAT I can set-up my account" which is essentially a starting point for the team to get together and discuss what's required to get it done.
3. Confirmation is essentially the acceptance criteria which at a high level is the test criteria confirming that the story is working as expected. Example of an acceptance criteria could be "The user gets a confirmation email on sign up". Please note that acceptance criteria cannot contain basic elements like code reviews and testing etc as these are not negotiable.

So I got a story, what next?

1. Once you have a story, the next step is to discuss it with the team and make sure it's got enough information for everyone in the engineering/design/testing team to be estimable. Tip, if Product Owners/Managers and Scrum Masters in your team are participating in the estimation of stories, you're doing it wrong.
2. Once the information is there, get a estimate on how much effort it takes to get a story done. This can be tricky if you just ask "how many days?" - the idea is to ask the effort it requires compared to another story (potentially recently completed). Example, if the story just completed was 3 points, what's this new story worth compared to the one completed? Here's some information on User Story Estimation from the horses mouth that you may find useful. Tip, it's a good idea to have a chart of a few completed user stories and their points next to them on a wall in the estimation session so people can estimate with context.

What's the benefit of writing good user stories?

Writing good user stories will help you to generate traction, achieve business outcomes, get team engagement, bring users closer, boost transparency, foster collaboration, manage expectations through shared understanding and most importantly have fun.

If you're purely in a delivery setup (not as much fun), you may just want to release as much as possible and on the other hand if you're in a discovery+delivery setup, you may want to release a little as possible; whatever be the case - good user stories are the key to achieve outcomes prioritised by risk to the business or value to the users.