Everyone likes a good story. We all know what to look for in a story, and it's not hard to tell whether we like a story or not. When it comes to Agile development, however, it seems that a great number of developers have difficulty recognising - and writing - good quality stories. This is unfortunate, because well-written user stories are crucial in unlocking several of Agile's key benefits.
This is the first in a series of articles I'll be posting, each discussing a different aspect of a good user story. Before I do that, though, I'd like to step back from the subject a little and look at why it even matters. I've often heard developers - including my own colleagues - say that user stories, backlogs, Kanban boards and all the associated techniques commonly seen in Agile processes are "just for management". In other words, they're seen as unimportant; meaningless overhead whose sole purpose is to placate middle management by giving them something to mess about with while the developers get some work done. This is a dangerous attitude, and is indicative of someone who has rather missed the point of what Agile aims to achieve.
Why Stories Matter
Story boundaries are pivot points
Agile is all about reacting to change - change in the market, the business strategy, the state of the technology, or the team's knowledge and skills. Regardless of the reason for change, the result is often that the plan will shift, and often that means changing what the team is working on. The risk here is that switching tasks can often result in wasted work, where you've built half a feature and now the other half isn't going to happen until later (or at all).
A well-written set of stories is your best defence against this sort of wasted effort. Any story might be the last one you work on before the company decides to change direction, or change priorities, or cease development on the product. This means that each and every story should add value to the product, and any story that doesn't is work that risks being wasted.
Stories are building blocks
Each story corresponds to an amount of work that the team will do to implement that functionality. When planning a sprint, these units of work form building blocks that you can measure with respect to your capacity and velocity, and fit together to form a sprint's worth of work. Any story that requires another story to "finish off" the work at hand is invisibly tied to that other story. Imagine building a wall, but each time you pick up a brick, a random number of other bricks come with it on invisible strings. What should be a simple task of slotting the bricks together now becomes a complex game of follow-the-thread to work out how to make it all fit. Neat, self-contained stories make sprint planning easier by increasing the number of ways you can fit your stories together, giving you more options and therefore more flexibility.
This is particularly important if you're the sort of team who commonly finds themselves pulling in additional work later in a sprint - if your stories have strings attached, then you'll find it a lot harder to find one that you can bring into the current sprint without dragging a whole heap of additional work with it - work that probably won't fit in the time you have left in the sprint.
Stories are blueprints
A developer tasked with implementing a particular story should be able to understand that story simply by reading it. The more interlinked your stories become, the more likely it is that your descriptions and your acceptance criteria will become scattered across the stories of a linked group, forcing the developer to piece together several stories in order to build up a clear picture of what it is they're supposed to be building. If a story needs some information, add it right there in the story. If you find that your stories start to overlap a lot, then consider whether they're actually aspects of one, larger story.
This can be difficult to judge, and in some fields, application functions and features tend to be very interlinked just because of the nature of the problem domain, which can lead to this cross-pollination of information in user stories. This can often be mitigated by moving contextual information to a central place, like a wiki, and letting each story contain only the bare minimum information required to judge whether you've met the acceptance criteria. (In fact, this is generally a good idea anyway, but that's a topic for another article.)
Stories are universal
A user story is something that everyone can read. From genius software engineer with decades of experience to a worker in a totally different industry who is utterly clueless about computers, anyone can read a user story and think about the person it describes, the job that person is trying to do, and the problem they need to overcome to succeed. This enables conversation and discussion in terms that everyone can understand, removing barriers to understanding between the people building the software and the people who are going to use it - and the easier it is for these two groups of people to communicate, the more likely it is that the end product will be useful to those who receive it.
User stories are crucial in Agile development; when properly employed, they enable and promote the core aims of Agile development: responsiveness to change, easy communication between developer and customer, accuracy of requirement capture, and ultimately, the production of useful software. In future articles I'll be exploring some common pitfalls in the writing of user stories, but until then, hopefully this article will give you some compelling points to use in explaining the importance of user stories. Like any collaborative process, software development works best when everyone is engaged and communicating, and simply convincing the whole team that good user stories matter can often be enough bring about real improvement.comments powered by Disqus