There are certainly many myths swirling around when it comes to user stories. Even calling it a user story causes some confusion, as the concept of a “story” is misleading. But whether your team is struggling with writing them, splitting them, or simply organizing them, a broken user story process can be a huge obstacle to success.
Whatever you choose to call them, user story models are the most popular way of writing agile software specifications. Because of this, they are absolutely integral to Scrum-based development. So it comes as no surprise when some companies failing with agile are still trying to write (and work with) old school specifications.
That’s why getting your user stories straight is such an important piece of the software development challenge. At Ascendle, we make sure that writing effective user stories is always a huge point of emphasis for our teams. But for many companies struggling to find results with Scrum, one common theme I’ve seen time and again is poorly written user stories.
With that in mind, here are three of the biggest mistakes I’ve seen companies make in their user stories:
1. Don’t tell the project team how the software should work.
Telling your engineers how to write software should never be part of a user story. Yet all too often, business teams tie the hands of their project teams by laying out too much detail. Why is that bad? Because your project team has the experts on it, and they’re the ones who will be doing the work. It’s much better to rely on their expertise to find the best, most efficient ways to build the functionality.
The development team should, of course, be involved in the creation of user stories. And it’s in their best interests not to include all that unnecessary detail. But sometimes, the business team has a little too much influence on the process and starts dictating not only what needs to be done but also how the developers should implement those needs.
User stories need to explain any conditions, pre-requisites, or additional info that may tie into the feature’s results. And for that, the business team’s knowledge is instrumental. But how the software gets that information, processes it, and displays results should be left to the project team.
One of the responsibilities of a good product owner is to make sure your user stories describe only the behavior of a feature. Allow your development team to decide on the best ways to accomplish it.
2. Don’t accept user stories that are too big for a production sprint or which alter the length of your sprint.
Another big mistake I see companies making is not splitting their user stories enough. They get to a point where they think they can’t break it any further and stop. Sometimes they’ll fill an entire production sprint with one story or even make the sprint longer than usual to accommodate it.
A production sprint should be just long enough that the team can build up some momentum and accomplish something meaningful… but never so long that it holds up important priority changes that might occur during its course. This is critical because one of the principles of Scrum dictates that work within a sprint is absolutely NOT subject to change requests. In other words, once a sprint gets started, there’s no stopping it.
In our experience, this translates into sprints that are two weeks in length on average and four at the outside. That doesn’t mean that each user story should be that length, however. Our rule of thumb at Ascendle is that no single story should fill more than 25% of a sprint’s capacity.
So what do you do with those bigger user stories? Break them down.
3. Don’t waste time.
As I mentioned before, some folks are confused by the term “story.” They think user stories should be detailed narratives that lay out each and every possibility a user could encounter.
But a true user story is just the opposite – it’s a lightweight specification that allows project teams to fill in as many details as possible with the most efficient solutions. As such, user stories should provide all the detail the development team needs to have and little else.
The same goes for all those obvious details tending to clutter up specifications documents. Avoid those because they’re a waste of time in both writing and reading. Obvious details make it harder to find and get to the more important info you should be focusing on. And remember, your development team is just that – a team. So you don’t need to decide if every single person will understand every single reference. The team can fill in any individual gaps.
Writing Good User Stories
Despite all that’s been written, creating good user stories remains a challenge for many companies. That’s because there are plenty of guidelines but few hard and fast rules. Truth be told, there’s an element of creativity in determining how to split user stories. You could say that it’s part science, part process… and part art. At Ascendle, we know how important this topic is, and we’ve invested a lot of time developing our user story techniques. For more on how to write your own good user stories – and avoid those common mistakes – read our blog post.
