Creating a Project Backlog: Breaking down product ideas and requirements in to TFS2010 User Stories (PBIs)

It’s kind of amazing how much hidden detail and complexity there is in even the simplest software product and application ideas. 

I lead a .NET user group that meets in Cambridge, MA called Beantown .NET.  Although I delegate some of the management of the group to other people, it essentially is my responsibility to schedule meetings, find speakers, manage the website, send out meeting invitations, and manage the RSVP list.  It’s not all that hard but lately I’ve been thinking that this could be streamlined and would make a good Windows Azure application.  A couple of days ago, I started taking some notes about what I wanted.  Here is what I wrote down:

–    Add Meeting
  –    Meeting Id
  –    Topic
  –    Date
  –    Speaker Name
  –    Bio
  –    Abstract
  –    Location
  –    Attachments
–    Meeting RSVP Viewer
–    Export RSVP List
–    Send Invitations
–    Send Reminder
–    RSVP To Meeting
–    View/Edit Members
–    Send Test Email
–    Edit Email Template
–    Join Beantown

Not too detailed.  Just enough to start to give my thoughts some shape.   

Since I’m a Scrum and Team Foundation Server 2010 guy, I decided to try to turn this in to a Product Backlog and put it in TFS2010.  A Product Backlog is the grand wish-list for the product.  In this case, the product is the website for the user group and the tools to manage it.  If you’re using Scrum, the backlog is made up of Product Backlog Items (PBIs).  In Team Foundation Server 2010, the backlog is made up of User Story work items.  Whether you call them PBIs or User Stories, the idea is that try to describe what a user of your application wants to do, what kind of user the person is, and why they want to do that thing.  This “who? what? why?” usually turns in to a sentence that looks like “As a <type of user>, I want to <do something> because I <reason>.” 

Now, I’m kind of a food nerd and I do a lot of cooking.  When you’re making some kind of bread or you’re making pizza dough, it involves a series of steps of the course of hours or days.  In between these steps, the yeast is working on the dough causing it to rise and change flavor.  If you let your dough rise for 2 hours, you get a reasonably flavorful dough.  If let it go for 8 hours, it’s much better.  If you leave it for 24 hours, it’s worlds better.  (My $0.02, you need to let pizza dough rise for 24 hours.)  Your brain does similar stuff and when you’re working on User Stories, software architectures, or class designs and it’s helpful to walk away from time to time and let your brain work on the problem in the background. 

So, the next day, I came back and tried to turn my notes in to some actual User Stories. 

Here’s what I came up with:

–    As a user group leader, I would like to schedule a meeting so I can begin the process of promoting the event.
–    As a user group leader, I would like to send out invitations to a meeting by email.
–    As a user group leader, I would like to send out a test meeting invitation so that I can verify that the invitation email is correct.
–    As a user group leader, I would like to send out an email reminder about a meeting.
–    As a user group leader, I would like to see a list of user group members so that I can view the details, edit, create, and delete members.
–    As a user group leader, I would like to edit an existing member.
–    As a user group leader, I would like to edit the meeting invitation template.
–    As a user group leader, I would like to edit the meeting reminder template.
–    As an invited member, I would like to RSVP for a  meeting.
–    As an invited member, I would like to un-RSVP for a meeting.
–    As a user group leader, I would like to view the RSVP list for a meeting.
–    As a user group leader, I would like to export the RSVP list for a meeting so I can use the list in other applications like excel, email, or in printed form.
–    As a user group member, I would like to unsubscribe from meeting announcements.
–    As a non-member, I would like to RSVP for a meeting and optionally be put on the email list.
–    As a non-member, I would like to join the email list so I can be invited to future meetings.
–    As a user group leader, I would like to post attachments related to a meeting so that anyone can download them from the website.
–    As a visitor to the website, I would like to view upcoming meetings.
–    As a visitor to the website, I would like to view past meetings.
–    As a visitor to the website, I would like to download files related to previous meetings.

In less than 10 minutes, I came up with 19 user stories and identified 4 different kinds of users — “user group leader”, “website visitor”, “non-member”, and “invited member”.  From a fairly simple idea, “hmm…it’d be nice if managing the user group were a little more automated”, I’m starting to see that there’s a fair amount of complexity here.  Looking at the list, I’m already starting to wonder if my product backlog is disorganized and perhaps going to be difficult to manage.  So, I re-read the User Stories and tried to identify some higher level stories that I could use to group stuff together.

– As a user group leader, I need a way to schedule and manage meetings.
– As a user group leader, I need a way to manage the membership of the user group.
– As a user group leader, I need a way to manage attendee invitations and RSVPs for meetings.
– As an invited member, I would like to RSVP for a meeting.
– As a member, I would like to manage my profile information.
– As a visitor to the website, I would like to view information about the group.
– As a user group leader, I need to display past, present, and future meeting information so that people can view over the internet.

Once I got the top-level stories identified, I put all the stories in to TFS and along the way, I started finding some other stories that I had forgotten. 

Here’s my product backlog in TFS2010:

Here’s a picture of my Stories Overview Report in TFS2010:

Here’s a link to download my TFS2010 Stories Overview Report.

Anyway, it’s never stops amazing me how such apparently simple ideas can turn hide so much complexity and detail.  This is just the functional requirements.  There’s still going to be non-functional requirements like security.  When we actually start trying to plan our development Sprints and turn these User Stories in to Tasks, we’re going to surface even more details and probably a bunch more User Stories.  When you start thinking about it, it’s no wonder it can be so difficult to deliver a project on-time and on-budget.  If you don’t go through an exercise like this on your projects, you might spend MONTHS thinking that your application is nearly finished and that you’re just about ready to deliver it.  It’s good to not be delusional about your projects, huh?  

-Ben

— Need help adopting Team Foundation Server 2010 and Scrum?  Want help getting your Product Backlog under control?  Need some training on unit testing or Visual Studio 2010?  Drop us a line at info@benday.com and check out our new Scrum Developer course.