Define your Users, and keep in mind it doesn’t always mean the End User

In general the End User, ie the external B2B or B2C customer actually using your app – is the person you are trying to make happy.

In development however, many times your User Story has an internal User that you are making something for.

IE User Story: As a Programmer, I’d like to see File ABC commented so that I can understand how to update the file.

Your End User will ultimately see a better product with commented code, but really – a programmer jumping on to a file will see the immediate value of commented code, and that is your User for this story.

Keep it high level – User Stories are not tasks

Maybe you have a very specific directive – to update the header on a page so that it holds one of the company’s new colors – Forest Green – hex code #228B22.

You don’t write Change the header to #228B22.

You write As a website User, I’d like to see the website header show the company color scheme.

This is an open-ended statement, and that is the point. It will lead to discussion among the team about what other parts of the website’s color scheme.

Under the sub-tasks, you can write that you want to update the header to Forest Green – hex code #228B22.

In fact, that is so specific you could make an Update home page to the new color scheme sub-task, and have updating the header as one bullet point.

But in general, the User Stories are not tasks.

Don’t eliminate – prioritize instead

Stakeholder needs change all the time, and there is always more work than can be done in one Sprint. So if a User Story falls off your to-do list, try not to delete it, or even archive it. Push it down the backlog, and three Sprints later things could change again, and it might return to the top of your queue.

Acceptance is the minimum – Success is the goal

You want the update to pass QA of course, but keep in mind that you want the User Story to-do well.

You need a bit more than It works as it should.

So be sure to add metrics to the feature—can you measure engagement on the page?

Can you measure how much the update impacted subscription?

This might be another User Story, or might even be sent to the Business Intelligence team, but keep in mind that User Stories are more than just about making a Minimum Viable Product.

Tag User Stories with metadata, and then tag some more

User Stories get re-prioritized, and yes — they get archived as well.

And then you have hundreds of them.

How will you find them later?

By tagging with metadata. By categorizing. By adding comments explaining why you pushed them down the backlog.

The User Stories should have a single good title and a single good description, but beyond that – tag, categorize and comment quite a bit.

Categorize your User Stories in terms of Epics

Epics are larger User Stories that often require many User Stories, spread across multiple Sprints.

For example—Redesign Payment page.

That can take a Design Sprint, a Desktop and Mobile set of User Stories, testing—you get the idea.

But still, all these User Stories are under the Epic Redesign Payment page.