In Agile, there is the concept of “stories” or “User Stories”. What are stories? Well, maybe it is best to look at what they aren’t:
- They aren’t projects
Stories are smaller than projects, by a long shot. A group of related stories is called an “Epic” but even then an “Epic” isn’t a project. But again, it all depends on how you or your organization defines a “project”. An agile team can focus on one project throughout their entire lifetime. Another might work on multiple projects, it all depends on how things are set up. But stories aren’t projects. Projects are made up of stories. - They aren’t tasks
Stories should be bigger than tasks. Each story should really take a few to many tasks to complete. You can get into the mindset of breaking up everything into tasks, but then you might be going to granular. You want your stories to be small enough to get completed within your sprint, but also big enough to not take 10 minutes to complete. - They aren’t direct requests
What do I mean by direct requests? A direct request from and end user or customer doesn’t directly relate to a story, it usually ends up being multiple stories. In the case where the request is just one story, it probably should be reworked to fit the mold of a story. - They aren’t features
They might be feature requests, but like “direct” requests, usually a feature request ends up being multiple stories, or if the request is small enough to be one story, it needs to be reworked to become a story. - They aren’t bugs
same as direct requests and features. - They aren’t day to day operational actions
Some people might get into the mode of “well, we do this every day, so it should be a story”. No… it shouldn’t. It should be what you do day to day. Your velocity will get adjusted by your do’ers doing things day to day, but you shouldn’t storyize day to day things. Would you create a story for your commute? For reading email? For lunch? The only thing you might want to storyize is an architecture type meeting, where the deliverable is a bunch of stories. I like the idea but I’m not 100% sold on it yet.
Well, so there is a short list of things stories aren’t. So what are they?
I would say the most key part of that story format is the end. The business value. Without that you are spinning your wheels, you don’t know why you are doing something.
What about things that go along with a story?
You might write the # of a record in your virtual system to easily correlate. Depending on your process, you might hand write cards (I personally like this method). Or you might print them. What about other notes? As a developer or do’er you might write things on the back of the card for when you pass to QA or the validation of the story, or just to keep things in the open. If you use a virtual system, you might have extra notes or background info so the do’er can actually do it.
I like to have a small title, and then the story.
Example,
As a sales executive, I would like to be able to see my sales and goals by product and year so I can better analyze my commissions.
A title might be “Adding goals/sales to cube for sales”
I also like to have a “component” when working on a team with multiple mini projects that might be getting done. “Sales Cube” might be a good component for the story above.
What else do stories have? Priorities and Scores. More on that later..
Steve Novoselac's Blog 