Here are my thoughts on User Stories
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.
Sticky notes are for some teams, but not for every team
A wall full of sticky notes serve a constant reminder to your team where everyone is, and the notes also serve to establish your team’s corner of the office.
And some teams really respond to them.
But they are not for everyone, and not for every team.
Maybe you don’t have the space, or maybe your team moves around a lot.
If they are not for you, and not for your team, feel free to employ Trello, or an equivalent program.
Trello even have Post-It Note to Trello integration!
Some teams are even great with Jira alone. In any case, it is up to you and your team.
Visualizations are great, photographed sketches on the whiteboard are great as well
If there is a photo or image encapsulating what the User Story is about, feel free to add it.
If the Product Owner, or anyone else, does a sketch on the whiteboard to explain that—take a photo with your phone, and attach it to the story.
And if you can
You don’t always have the time or resources for this but if you can—
Have your team write the User Stories
Some companies allow time for this, others do not. But involving the team in the User Stories allows everyone to understand the Sprint as a whole.
Another technique for this is to occasionally have each team member sit at the front and type the story – it gets everyone involved.
And don’t forget to
Think big. You do have time for this so—
If there is a crazy idea that you or someone on your team has, write it down into a User Story.
Maybe someone wants to add an entirely new feature, or someone has an idea to eliminate Technical Debt.
Maybe someone wants to add a section with augmented reality.
If it has value to the User, make a User Story about it. Don’t worry about budget or resources, or anything else.
Write it down, and you never know—you might have time in the upcoming Sprint, and it just might happen.