Chris asks:
What is your opinion of “stories” which some web development shops write? A Ruby on Rails development shop I have worked with writes a “story” about every piece of functionality they intend to develop. They use those stories to ensure all customer objectives are met. They’re similar to use cases (maybe identical!)... functionality represented as a sequence of simple steps in writing.
We believe in interface-first driven development, but when the UI or feature needs some further explanation we write a story.
A story is usually a paragraph or two. Sometimes it’s 5 bullet points. It’s not an in depth dissection of a feature, or a technical discussion of what needs to be implemented. It’s not a functional specification. It’s simply a general idea of what the feature is about and why it’s valuable.
For example, we’re working on some stuff for Backpack right now. One of the areas we’re looking at is making it more obvious someone changed a page since your last visit to that page. The story might go like this:
Right now it’s tough to know if a Backpack page has been changed since the last time you’ve seen it. If I’m sharing a page with Bob, and Bob adds a new to-do list or a note to the page, it should be clear to me the page has changed next time I visit that page.
This story may be enough to explain why the mockup we design has a yellow strip at the top saying “Bob changed this page. See the changes.”
The story serves to add some context. It doesn’t need to say exactly how to solve the problem, it doesn’t need to refer to specific design elements, and it’s not technical. It’s just a statement of why something is a hassle (“don’t know the page changed”) and a general idea of how we can make it better (“make it clear the page changed”).
The actual solution is presented in the interface design. We may go with a yellow strip or some other notice. We don’t know yet. We just know it should be clear and obvious. The rest happens as we toss around some design ideas.
We’ve definitely found stories to be handy summaries of big picture ideas. But it’s still the interface that drives almost all of our development.
Got a question for us?
Got a question about design, business, marketing, etc? We’re happy to try to provide some insight into how we’d tackle the problem. Just email svn [at] 37signals dot com with the subject “Ask 37signals”. Thanks.
Bob Walsh
on 18 Dec 07FYI, the links (headline and comment) on “10 ways to get ink” are broken…
Chris Cocca
on 18 Dec 07In my experience, ‘stories’ play a big part in Agile project planning.
Stories are easy for all stakeholders and users to understand – this makes it easy for them to point out errors/omissions. They’re also a great way of getting stakeholders to prioritize what should be done for the next iteration. We’ve had some really good success with them so far…
Kevin Mackie
on 18 Dec 07I think stories are great. I would reckon that the majority of our use cases start out as stories, then the use case is elaborated to ensure we’re considering all of the alternate and exception flows.
We differ from Jason’s approach in that we would flesh out those use cases before doing any interface prototyping, but that’s likely a function of how different our software is. We’re one of these big, bad ERP vendors (boo, hiss :-) and any agility we’d like to have has to be tempered with the risk of breaking how are customers are actually using the software.
To us, stories are a centerpiece of user-centric design.
Tammer Saleh
on 18 Dec 07We do things pretty much the same as Jason described. We develop UI mocks first, and add short “stories” to clear up the confusing bits.
I’ve worked with groups that are entirely story driven, and I just found it to be confusing and overwhelming. I’ve found that mocks present the information much better than stories do, and in a much more concise and easy to follow manner.
Derick
on 18 Dec 07Interesting….I am always torn when writing feature suggestions etc. between telling the full story that led to my suggestion & just stating it directly.
Since it’s relevant to the topic and the particular case—one of the ways I use backpack is to manage my trips to the library. In addition to posting materials I want to pick up & keeping links to my circulation record, I have all my e-mails from the library forwarded to my backpack page. So I’m excited to hear that BP is likely to get some upgrades that will show when content has been added/changed & hope that extends to incoming e-mails.
But there’s another part to my story…..unfortunately the e-mails from the library have the subject line “Library Circulation Notice,” whether they refer to an overdue book or to something which has arrived for me to pick up. The way BP works now, I need to click on each e-mail to see its content. What I’d prefer is an inline preview of the first 5 or so lines, like in Highrise.
So….when you go about adding inline previews to BP, you can think of my story :)
Matt Allen
on 18 Dec 07The new Rspec Stories are a great way to to turn actual text stories into actual BDD tests.
Bob from down the hall
on 19 Dec 07But what you just gave for an example isn’t a story at all! It isn’t even a specification! It is vague and useless. What does “should be easier” mean? What does “is to hard right now” mean? How does those these sentences help any more than somebody telling you “dude, your todo list notifications suck, please fix them”? How will you know if you’ve actually fixed the problem when you haven’t even defined the problem?
A good story should answer the “why”. Why does Bob want to know when a task has changed? What goal was he trying to accomplish? Why are you sharing a to-do list with him? What do you hope to accomplish by doing that? Does he want your to-do list?
The problem is you aren’t thinking holistically about the problem. Your story is about as low level as a database schema diagram. If you actually used your story, you’ll run the risk of programming to the tree instead of to the forest. Maybe you dont actually need the feature? Maybe there is a completely different way of handing changed tasks? Reading that story, you’d never consider other options.
It is all about the goals. What is the goal, and what is keeping the user from accomplishing the goal. If you write your story framed as “How we handle todo lists suck because they interfere with bob’s goal of $bob’s_goal. We should do $XYZ instead because it makes bob’s goal easier”. Maybe todo list changes aren’t even part of bobs goal? How would you know without talking to bob (in the form of a persona based on interviewing a couple bob’s)?
Brian
on 20 Dec 07I couldn’t agree more. Stories are a crucial part of our development at LOUD! Creative. It’s a must.
Brian
Jared White
on 20 Dec 07I’m working at a company that uses stories (along with the Scrum process), and it works out great. The major problem we’ve had is that the product managers may write a story, but if various people in different teams are talking about changes or clarifications after the fact, that MUST get back into the original story documentation/mockups or the end result will be confusion and chaos. We’ve been trying to get more diligent about updating the official repository for docs and mockups, as well as setting due dates on individual deliverables, and it’s been much better.
So yes, stories are awesome, and work so much better than the gazillion page swamp known as a requirements document that I’ve had to deal with in other companies.
Seth Surchin
on 21 Dec 07(While you are on the topic of Backpack development and user stories) I can come up with a request that requires no story to validate—make individual to do items “drag-able” between Backpack pages!
(Going by the customer fora) This has got to be of greater value than indicating a change on a shared page, the example 37S cited in its post.
Forgive me for posting a feature request here but this one has been in the feature requests list on the Backpack customer forum for some time without any follow-up from the 37S team…
This discussion is closed.