There are five big mistakes I see teams commonly make when working with user stories.
Fortunately, each is easy to avoid once you're aware of the mistake and why it's a mistake.
First is thinking that every user story needs to be small.
Small stories are great, and I want to bring only small stories into a Sprinter iteration.
But larger stories can be useful.
You should prefer large stories when it is not something you are going to work on imminently.
Suppose you have just begun work on a new product that will include a set of reports.
If asked, you can list some but not all of the reports that will eventually be needed.
And since this is a new product, none of their reports are needed immediately.
There is nothing to be gained by writing a bunch of small user stories at this point, especially since you don't yet even know all the of reports will
be need.
You could go interview a lot of users and stakeholders and perhaps get close to a complete list, but in most cases that work is better done later.
Having one big reporting story rather than a bunch of little stories keeps the size of the backlog more manageable.
You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.
Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything.
Early in a project, that's probably not true.
New reports will be identified, and some that are asked for initially may not be necessary.
So if bigger user stories are OK, when should a team split them?
Second in our list of mistakes is waiting until sprint planning to split user-stories.
Sure, some stories will absolutely need to be split during sprint-planning.
The common case, however, should be for stories to been split prior to the iteration or sprint plan meeting.
Many teams conduct backlog refinement meetings.
These should ideally be held two or three days before the start of a new iteration.
I view a product backlog refinement meeting as a pre-planning checkpoint.
It is a chance for the team and product owner to discuss the work that will likely be brought into the next iteration.
This should include whether high-priority items are small enough.
Any that are not should be split at that time.
Routinely breaking large stories into smaller ones during sprint planning makes that meeting take longer, and it's too late for the product owner to realistically
act on information provided by the estimates.
If stories are split sooner, it gives the Product Owner time to prioritize each.
Think about our large reporting story being split into a set of smaller stories, each representing a different report.
Some reports are more important, and the estimate to develop each should influence how each is prioritized.
Splitting small stories out of the larger stories prior to the iteration planning meeting gives the product owner time to make these decisions.
Let's look at a third big mistake teams make with user stories, thinking that everything on your product backlog needs to be a user story.
I get it.
User stories can be really helpful, but you don't want to use stories the way I cook with basil.
Yep, even chocolate chip cookies.
The purpose of a user story is to facilitate communication and understanding of users' needs.
Expressing a users needs in a story, is very helpful when there are nuances to what the user wants, but it's not always necessary.
Let me share two examples.
First is technical changes or enhancements.
A backlog item like upgrade the Linux server is perfectly fine.
In fact, it's preferable to something like, as a user, I want this system hosted on the latest version of Linux so that the system is secure.
A second example is bugs.
Teams have been writing bug reports since cavemen wrote the first line of code.
Writing, this system blows up when I enter a negative amount in the value field is good enough.
Naturally, supporting notes should be provided, but there's nothing to gain by writing most bug report as stories.
Additionally, some product backlog items you might be tempted to write as user stories might better as job stories.
Job stories are an interesting alternative to user's stories Job Stories de-emphasize who is doing a story and instead emphasize when the story occurs
and the job the user wants to accomplish.
I've got a video about job Stories that I'll link to in the description.
Another mistake teams make is slavish devotion to a template.
The, as a type of user, I want some goal so that some reason template, has become extremely popular.
It's a good template and it forces us to think about who wants the story, what they want, and why.
But I've seen teams go to the extreme of insisting everything be written in this format or it's not considered a user story.
A user's story can be any short, simple statement that helps stakeholders or users and the team discuss a user's need.
I think using a template is a good starting point, but not everything on your backlog needs to fit neatly into the same template.
A final mistake teams make is writing stories too far ahead of when they'll be developed.
I don't encourage writing the stories this week that you'll do next week.
It's good to have a vision or direction a couple of months ahead and to write stories for that horizon.
But when possible, you want to avoid having a backlog that stretches much further than that into the future.
There are exceptions to this.
If you're working on a fixed price project, you'll often need more of a backlog.
Similarly, if stakeholders need a roadmap of future deliverables, You may need to create a back log stretching that far.
However, remember the advice to use larger stories when looking that for ahead.
Larger stories won't include as much detail, but capturing a general future desire will often serve you better than trying to think of every little story
that users will want in the future.
Avoiding these five mistakes will help you create a product backlog that will set your product up for success.
If you found this video helpful, please do me a favor and hit the like button.
It really does help YouTube know to show the video to others.
And click the subscribe button if you'd like to be notified of future tips.