As mentioned in the previous tutorials, I suggested building spreadsheets of your tasks. Specifically, I’m talking about using shared google spreadsheets. Build one spreadsheet, and add sub-sheets to it. Don’t juggle multiple spreadsheets use URLs everyone in the team has to remember. Start your project out with one spreadsheet with sub-sheets. Make the first sheet that appears in it something general, like directions of how the whole sheet is organized, for example. Also, make the spreadsheet accessible via a public URL. Don’t do the whole “share” thing where you invite people. People have different gmail accounts and google apps accounts, and won’t be able to visit the link, and will therefore visit the link less (i.e. when they’re logged into the gmail account associated with it) and in some cases never. In general, when building software, reduce as much friction as possible between accessing available documents, code, etc. And if you have multiple documents, link to them all from the first page of the master spreadsheet and tell everyone just to bookmark that sheet.

Ok, so you started with spreadsheets. I love spreadsheets because they’re very malleable. You can add new columns for new data, new sub-sheets, etc. People can write comments in the rows, and it’s a great place to collaborate with very little friction. Once you’re done however, you need to transfer these tasks to your project management software.

So on a per page basis (and per state basis), we create written specs closely attached to the layouts, and organize these feature requests in FogBugz, Joel Spolsky’s project management software. Joel Spolsky FYI is the creator of Stack Overflow, and a famous developer from Microsoft who worked on the Excel project. Anyway, the key here is that the list of tasks are coupled to their layouts, and then that FogBugz is arranged in a way to mirror this association just like the sub-sheets represented one page, or similar global tasks. Sometimes you’ll have group/sheet of tasks just for one state in a page if there’s a lot of interactivity going on.

Other shops may do more of a Bottom Up approach, where specs are written in association with the underlying data structures. That’s fine, but not yet. We find the problem with starting with that  approach in $50-150k contract projects is that our clients can’t closely associate the tasks being executed to precise features you’re looking to see. If you’re small startup, even working internally with an inhouse team, you’ll be in similar boat. For example, a database structure may be prepared and it took the developers a week to do, but you, as an end user testing the system, will have no way to associate the completed tasks to completed features you can use, and then you have no idea what you’re developers were doing during that time. In other words, you must optimize your process so at all times you know what’s going on in the form of testable features. Later in the technical speccing tutorials, I’ll describe how you’re developers should pin-point technical spikes and create the tasks according to a more bottom up approach.

So back to organizing Fogbugz. In Fogbugz, you will create what’s called an “area” and we use each area to group all the tasks in one of those sheets, i.e. that mainly correspond to pages at this point. You’ll then create a “filter” that will group tasks by Area first. This will create neat groups on the page obviously. Later on you’ll also arrange the same set of tasks in a different “filter” that groups by open, resolved and closed tasks. You will do so on a sprint by sprint basis. We’ll cover this more in later in the Sprint Planning tutorial. The overarching idea is that Fogbugz allows you to create multiple views through which you can look at your data, and again these are called “filters.” For now we’re creating a simple filter to view all your tasks nicely grouped similar to your spreadsheet.

The next thing you will do is organize the columns in the filter so that only the columns you need show. These columns are the title and description and nothing else. You want to be able to look at just the data you need to know now about the product now, not how the execution of the product is evolving with columns for things like status, etc. Later on you may add “status” back to it, but this is your master “product backlog,” as they’d call it in Scrum (http://en.wikipedia.org/wiki/Scrum_(development)), which we won’t cover now because we’re focusing on our own precise techniques, rather than the history of how we’ve borrowed stuff from other methodologies.

The last thing you want to do, which may actually deserve it’s own chapter, is you want to create a sitemap of all your pages. We use: http://writemaps.com/ . That tool will let you build a tree style sitemap and then link out to pages on the web. So what we do at FaceySpacey is upload all the layouts to the web and link to these layouts from the sitemap itself. This way you can quickly visualize the application as a whole via the sitemap, and dive deeper to see each layout if you want. Then the last touch is in each sitemap icon we also put in the link to a fogbugz filter that filters tasks just down to the tasks in the area corresponding to that page. This way you can quickly navigate from the sitemap to an individual page layout and its corresponding product tasks.