User Story – Steve Novoselac's Blog

Not sure if you anyone has heard of or used “UserVoice” – It is a site that allows you to create “forums” for your products and then submit ideas, give users votes and they can vote them up, and an admin can say things are started, merge ideas, or mark when the idea has been completed (and the votes go back to the users).

UserVoice is (sorta) along the same lines as GetSatisfaction (another cool customer service 2.0 app). Pretty cool tools. If I was in a customer service role, especially with any type of user based or public product, I would be running these tools to gather ideas and feedback from my users.

I am in a technical role, so what I decided to do was “democratize” the development area of our product one of my teams is working on. We have a ton of technical debt (as do most teams, it is just a matter of what level of debt you have) – but what should we work on next from a technical perspective?

In comes UserVoice. Let’s throw out ideas on UserVoice, give everyone 50 votes, and the ideas that bubble to the top will become our next set of things to work on. One “idea” may become several “user stories” (we are agile). Our goal is to have 20-25% of our stories focused in on paying down our technical debt. If we didn’t, the debt would never get down to a low enough point to where we are very comfortable.

What is cool is that it really shows what the team wants to focus on next. People can have others vote up their ideas, etc. Also, getting the votes back at the completion of an idea is key. As you can imagine, our forum is private. The one cool thing about UserVoice is you can create multiple forums, with different ranges of settings, so you could also have a public forum, or a different private forum for a select group of users, etc.

One thing I wish I could do is maybe give different # of votes to different users. Integration out of the box with TFS or other systems would be nice too, I haven’t looked to much into that though.

If you have a team that ranges from medium to large, I would suggest checking out UserVoice to get the ideas and opinions of the members out on the table regarding your technical debt. You may be surprised as to what gets voted to the top!

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?

As a user/group/xyz, I would like new feature/bug fixed/thing done, for this reason/business value.

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..