There was a time when we were writing user stories to describe requirements. I’d say they worked fairly well for us. But we don’t do this anymore.
We were using user stories as a technique which allowed us to describe bigger chunks of functionality. There was one bigger sub-project or module and it had more than 10 user stories attached (usually closer to 20) and a handful of non-functional requirements. During development we were often going through several stories at once as technical design didn’t map directly to the stories. The stories were more of input to design session and a base for test cases than stand-alone bites of functionality.
Then we switched to Kanban. One of consequences was we reduced the size of average feature which was going to development. It no longer had 15 stories attached, but it wasn’t a single-story task either. If we were still writing user stories to each Minimal Marketable Feature we would probably have few of them. My guess is 2 or 3 most of the time.
At this level stories become pretty artificial. I mean if you think about 2 stories connected with one feature, i.e. administrator can configure this magic widget and user can use this magic widget to do, well, the magic, you can pretty much tell these stories intuitively in your head. Writing them down becomes overkill.
Besides that I think the often cited role of user stories which make usage scenarios completely clear is overrated. If you can talk with developers in language closer to the code, and functionality description is much closer to the code than telling user story, you’ll be better understood. The standard problem here was that functionality description wasn’t precise and it often became disconnected with usage scenarios.
The answer for this problem is: make features as small as possible (but only as small as they still does any difference). Small features are easy to define, easy to understand (even for a developer) and easy to chew. It is pretty hard to screw them.
There’s one more reason why I don’t consider user stories as a must-have. If you happened to create software which will be used by other developers or administrators at best, like some magic box with a lot of APIs and command line interface as the only UI, you should know what I’m talking about. If you write stories for this kind of software you end up with a bunch of “as a developer I want to call the magic function which does the magic” stories. Doesn’t API specification make more sense?
I don’t say user stories are bad. They aren’t. But they don’t add value all the time and in every situation. This is just another practice which should be used only as long as it does make sense in your specific situation.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
12 comments… add one
If you have a non-functional requirement like “Make the system secure”, how do you relate the particular feature to that NFR?
Alex,
We have a feature which is called something like “add security to the widget foo.” We also had ‘features’ like database performance improvement etc.
Of course that doesn’t mean we ignore all the non-functional requirements in the first place. Actually, talking about performance we set the goal on the very beginning: we should process not less than 150 transaction per second. If we didn’t have this goal in the back of our heads we could have a lot of work to fix the code when trying to implement the “improve performance” feature.
User story is a technique, it is not the key of success. If there is no user story, then just skip it – stick with NFRs or whatever drives the spec to success. Goal should be set on identifying problems and needs.
Personally, find increasing success with getting features defined as small as possible. Using a tracking system for all these small features wasn’t immediately received by the business/product stakeholders, but the control it gives them over exactly what, at a very fine granularity, of what they get and are not getting when, it making it a huge success. The word is spreading that this granular feature entry, define, re-factor, prioritize, dev, test and release is working well within the organization.
Simonas,
Exactly. Use cases, user stories, minimal marketable features are just means used to define requirements. We should choose ones which work the best in a specific situation.
In our case we found user stories an overkill as we switched to defining minimal marketable features so we stopped creating them. They just weren’t bringing additional value anymore.
John,
In general the smaller features/stories/cases you define the better. It is because it’s easier to estimate them and there is less place to misunderstand them.
The only trick is if you go too far with making features small it will become ridiculous and counterproductive. It doesn’t make sense to deal with features like “add a button here.” But we most of the time we have problems with too big features not the other way around, so we may safely follow “the smaller the better” advice.
This is by the way one of reasons I love to work in small teams. With small team and pretty limited throughput we are able to chop functionality down to pretty small chunks of work. With big teams and huge project it is way harder.
Pawel,
Again, your spot on. We use stories regularly but not for everything. Our stories are functions not features; they are very specific. Our Epics are what most would consider a story. The main reason for the granularity is that we have very small teams (3 to 4 developers), extremely short deadlines (3 day sprints and 5 week projects), and operate between XP (for original development) and Kanban (for test remediation/pickups/bugs, etc). It’ s a difficult process at the moment.
So for us, stories are a tool used for the original development process, seldom used for anything else.
Dave,
As you write: the size of story/feature/case plays more important role than its form. And the form can be pretty much whatever as long as it describes the requirement well. If people got used to user stories, that’s great.
For me personally user stories always were a bit artificial. I always thought in software features category. Pretty much the same is with the rest of the team. This by the way may be another reason why dropped user stories and don’t miss them.
By the way: don’t you think an uniform process for both original development and maintenance would be better? I don’t know the case of course but I always try to simplify things.
The point of user stories is mostly to force developers (primarily, but other stakeholders as well) to see their work from end users’ point of view. To put themselves in the shoes of the user, who will be clicking, dragging and performing other actions, and to realize that the goal of the feature they’re creating is not to get the tests to green but to help users achieve certain tasks.
If you have a team which already works with such a perspective, then it becomes much less important whether you’re putting requirements into user stories or not.
Michał,
I know the theory behind user stories but I rarely (if ever) see it working this way. It’s just semantics. If a description of a feature starts with “As a poor simple user I want…” it doesn’t really change the way developers look at it.
On the other hand it is exactly as you say – if developers are aware of who they create an application for and how users would act the problem becomes pretty much irrelevant.
Personally I see more value in showing the context in high-level (low-level too) discussions about the product. When a developer understands what the application should do in general, why it should work that way, how will use it and why specific scenarios are so darn important you will get much better results than just keeping the form of user stories for requirements while forgetting to describe you plant a forest, not this and that tree.
On the side note: making developers aware of big picture and business perspective should be one of primary goals for both manager of the team and product owner.
Hi Pawel,
Thanks for the interesting post. I was writing a comment about my ideas on how MMF’s fit with user stories but it started getting too long, so I blogged it instedd – http://www.upstarthq.com/2010/05/the-evolution-of-a-spec-epics-user-stories-and-minimum-marketable-features/
Cheers,
Chris
Chris,
I’m always happy to see people applying different ideas with understanding what they are doing and why. And that’s exactly why we end up with different approaches even though we use the same tools. By the way direct mapping user story to MMF isn’t something which is seen very often I believe.