In this article, I am trying to describe my own view on stories in product development and to share some efficient ways of working with them.
Let’s start, however, with the question of why there should ever be stories.
I have to mention that stories is just one of tools Railsware team uses to manage scope. And it’d probably be difficult to explain the full story here without getting into specifics, e.g. Inception, IBRs and prioritization. This article explains part of the full concept.
Quite often, as we know, requirements are being written not by developers and therefore not all of the dependencies, risks and technical debts are considered. When you hire construction workers to build a house, you wouldn’t expect to tell them how to lay the foundation or which brand of tools to use. It’s implied that professional workers know better what to use and how to build. What they really need to know is the end result you want to achieve, as detailed as possible. That’s the approach we try to apply to software development.
Years ago, requirement documents, client interviews, etc., have been disassembled into tasks by a project manager and developers have been taking them further on into production. Then, after a few pits we’ve got into, a certain insight came.
Task approach makes it hard to make sure you build the right thing. And the right thing quite often appears to be not exactly what the client said they want to build. We understood that we need to improve the product with every iteration and build what’s right for it. Together with the client, in an iterative manner and an agile product development approach.
Tasks very much depend on an original requirement which makes it almost impossible to understand new functionality benefits within the product context. “Implement Facebook authorisation” or “Integrate BrainTree payment system” are some good tasks examples.
The trick is that these tasks are pretty much clear and straightforward from the developer perspective. At the first glance, they require no questions. Developer can easily understand it, figure out how to implement and finally implement. Which is one of the pits we got into. Implementing tasks doesn’t guarantee you’re building a product. It also doesn’t mean product becomes better after the task gets implemented. Because a task doesn’t imply analysing anything apart from the development itself. Tasks don’t explain what for this functionality needs to be implemented.
With that said, task defines a method, a way.
As a solution, we came up with focusing more on writing stories instead of operating tasks.
Story is a short, simple, human readable description of a desired functionality. As opposed to a task, story defines a benefit, a goal, laving it up to the team which tool to use or which way to choose. Let’s see how.
Story does not contain any technical specifications or implementation plans. What it does contain is the following:
– role (“who”)
– feature context (“if/when”)
– feature action (“want”)
– reason/benefit (“so that”)
Role narrows down scope for the feature. It shows who will use it. For example,I as logged in user..I as administrator..
Of course, there are examples when story is written in a way it restricts feature usage for a certain role, but I’ll try to keep it simple in this article.
Feature context helps to understand conditions that feature should appear or work in. For instance,I as logged in user
When/if I visit homepage…
I as administrator
When/if I visit /admin URL…
In some cases, this part might be optional.
Feature action is the key behaviour you would like product/app to have within given conditions (in “who” and “when/if”).
Examples:I as logged in user
When I visit homepage
I want to see unread messages notifications count…
I as administrator
When I visit /admin URL
I want to be able to enter admin email/password…
It should not be mistaken with “reason/benefit”. I’d say this part can be called “developer’s benefit” because this is what developers treat as a benefit of the story :) They used to think in such way because they understand what happens beneath it on some subconsciousness level. “It’s crystal clear I will be aware of new messages if I see new messages count in homepage, there is no sense in explicit writing of that”, “It’s obvious I should be able to log in there if I see a login form” etc. We will try to talk about this catch more a bit later within the benefit explanation.
And finally reason/benefit. We prefer “benefit” more because “reason” sounds more like an excuse, than a value. Which is not a good match for the storyю
Benefit is WHY you develop this product at the first place. There can be no story without benefit and there can be no product without a problem it provides solution for. A good story should start from understanding the benefit of it. Why do we build this? What problem do we solve building this? Is this a problem really? Will product benefit from gaining that?
Getting back to “feature action VS feature benefit” question, seeing unread messages count is not a benefit. It’s a way to be aware of your unread messages if any. So, in this case, benefit would sound like “to be aware of unread messages when any”. Yes, its broader and can be provided other ways and that’s the beauty of it. When you’re presented with the destination, you can choose the path. But when you’re presented with the path, you can only start walking it, even without knowing if destination exists.
With that said, our examples should finally appear as:
I as logged in user
When I visit homepage
I want to see unread messages notifications count
So that I will not miss new messages
I as administrator
When I visit /admin URL
I want to be able to enter admin email/password and log in
So that I gain access to admin features
Stories should be written after the client interview or requirements analysis, but before any development of newly requested features starts. We’re doing this in pair with client, either personally or on a skype call, at least for the first two or three iterations. I can see no other way how stories writing value and importance can be demonstrated. When customer writes stories himself, his understanding of features, their context and, what’s most important, benefits improves significantly. Along with whole product vision.
Start with benefit and then proceed to the method of gaining it. Not vice versa.