Articles

Pivotal Tracker vs Basecamp: Project Management Tools Tested

Wednesday, September 23rd, 2015

We have been using Pivotal Tracker successfully for project management for a few years, and have grown to find it an invaluable tool for staying in sync with customers on our projects.

We were recently asked to join Basecamp to work with a client on several projects.  At the time, I made the request that we use Pivotal Tracker, but was unable to articulate the difference(s) that made Pivotal Tracker our tool of choice.

After using both now side-by-side (which itself was one of the reasons I preferred to stick with Pivotal – having only a single Project Management tool open simplifies our world), I now have enough experience with both tools to offer some comparisons:

Full Disclosure

Straight out of the gate, I want to be sure I’m clear: I have a fairly strong bias towards Pivotal Tracker.  If you believe something is missing or inaccurate in this article, or I’m misrepresenting either one of these tools, let me know.  While my bias is strong, I want to be sure that my facts are accurate.

Overview

Both Pivotal Tracker and Basecamp provide support for multiple Projects.  Within each project, you can have distinct “Authorized Users” who are able to work within that project.  The primary feature that both of these tools offer is collaborative task management, including discussion, for each task.  We find this very powerful for allowing our team, as well as our clients, to see and participate in all of the tasks that may be going on with any given project.

Pivotal Tracker Interface

Pivotal Tracker Interface

Basecamp To-Do view

Basecamp To-Do view

Feature Comparison

FeaturePivotal TrackerBasecamp
Task Management
Tasks support sub-tasks
Assign Tasks to Categories / Types
Task Due Datesonly some task types
Tasks Prioritization
Assign Tasks to an Owner
Assign Task to Multiple Owners
Task Discussion
Multiple Users Tracking Tasks
Daily Recap E-mail
Robust Task Workflow
Tasks Grouping
Same Task in multiple groups
Pricing Based OnNumber of UsersNumber of Projects
Free Plan
Free Trial Version
Pricing$3-$6 per user$2 or less per project
($1.50 - $6 per GB storage)

Task Management

For Task Management, Pivotal Tracker uses what’s called “stories”.  A story is typically a task, but can contain sub-tasks as well.  The definition of what a story represents (project, task, etc) is somewhat up to the user.  Pivotal has an interesting approach to viewing / managing stories, which is basically a “column” view, where each column represents some meaningful grouping.  You can hide or show columns as it suits you – whether it’s a single column for “My Work”, or (as I typically run), three columns: “My Work”, “Backlog”, and “Icebox”.  I will occasionally also have open an Epic or Label column, if appropriate.  Pivotal allows multiple projects, and your view is preserved from project to project, so when you return to a given project, the view is exactly how you left it.  Each story collapses into a short box that contains the most relevant details, for quick scanning of stories.  Moving stories up and down within a column (to imply priority) sticks.  To view the details of a story, including discussion, attached files, etc. – you simply expand the story.  If desired, you can open a story to “full size”, so that it essentially takes the full height and width of the browser space.  But the column view is how I typically work – everything happens within this view – you can add, expand, move, discuss, etc. right within the view – and that way everything is in the “context” of the full project.

For task management, Basecamp uses a “To-do list”.  While there’s a few views that Basecamp offers, I find myself working within the top level “To-Do’s” view of any given project. Within this view, you can see all To-Do’s across all Lists, and either drill into a single To-Do, or into the To-Do List.

Sub-Tasks

In Pivotal, the stories include the opportunity to describe (and track) separate sub-tasks.  This becomes useful for tasks that grow to include additional auxiliary tasks, or include several sub-items that aren’t worthy of separate stories.

Basecamps To-do’s do not support sub-tasks, but can be emulated using To-Do “Lists”, so long as you did not want to use Lists for another purpose (see the “Task Grouping” section below).

Task Categorization

Pivotal stories also include a set of “types”, so that a story can be assigned to a “type” (bug, feature, chore, or release).  These have useful semantic meaning, and also expose different features around the story.  (For the usefulness of these features, see the “Task Workflow” section below).

Basecamp does not provide any categorization of tasks (it does support To-Do “Lists”, discussed further in the “Task Grouping” section below).

Task Assignment

Pivotal stories also include the ability to define multiple “Owners” (the “assignee” of the story).

Basecamp To-Do items can have a single owner.

Task Discussion

Pivotal Tracker provides an “in-story” discussion tool (called “activity”).  This activity allows the user to enter comments, questions, attach documents, and provides syntax / formatting using Markdown.  (Markdown is a set of convention that allows formatting.  For example, to bold a word, wrap it in two asterisks: **this will be bolded**, to italicize, wrap in single asterisks: *this will be italicized*.)  Markdown is convenient, but more complex markdown formatting can be intimidating until you become familiar with it.  Discussion is also supported at the “Epic” level (see “Task Groping” below for more information on Epics).

Basecamp supports discussion both within a To-Do, as well as at the To-Do List level.

Continue reading the “Following Tasks” section for further information about Discussion.

Following Tasks

Pivotal Tracker automatically causes the Story requester (which can be changed), as well as any story Owners, to be followers.  This means that any discussion for a story is automatically copied by e-mail to the requester / owner.  Additionally, Pivotal Tracker will allow anyone authorized on the project to “Follow” a story as well, which will cause them to be updated on discussion.   Lastly, when discussing a story in Pivotal, you can include anyone who is authorized in the project on discussion by citing them using the convention “@username”.  So, if I wanted John Smith on my team to be included on some communication, but he was not the requester nor an owner of the story, I simply drop his username in.  When you type the @ symbol and begin typing, Pivotal prompts you with the authorized users, so you can select quickly if desired.

Basecamp also automatically causes the To-Do creator (which does not appear to be changeable), and the To-Do assignee, to be followers.  Basecamp also provides a simple interface in discussion to check checkboxes to include authorized users on the discussion, as well as a convenient “Loop-in someone who isn’t on the project” to include someone outside of the authorized users if desired.

One thing Basecamp does that is nice is that they send a “daily recap” of activity.  No such feature appears to exist in Pivotal.

Task Workflow

As mentioned, Pivotal supports different story types (remember, a story is typically a task).  Each of these reveal different features around the story.  One of the more useful features is the workflow that is implemented for certain task types.  There are four task types: bugs, features, chores, and releases.  The workflow that bugs, features, and releases create are a “process” that makes a lot of sense: Before the story is started, it is in the “Unstarted” phase.  The owner of the story can then “start” the work, once they are done they can “finish” the work, but “deliver” it in a separate explicit step (which is useful for communication with clients).  Once a story is delivered, then it can be approved / rejected.  In our workflow, we typically ask the requester (the client) to review and approve / reject the work.  Pivotal does frustrate a bit in this area, though – the only story type that supports due dates are “releases”.  It would be nice to expose this option for other story types as well.

Basecamp To-dos do not provide much workflow.  When an item is complete, there is one step: check the checkbox to mark it complete.  You must explicitly ask for it to be reviewed, if desired, and if it is deemed inadequate / incomplete, you would un-complete the task to re-activate it.

Task Grouping

Pivotal Tracker accomplishes task grouping in a couple of interesting ways.  First, any story can have one or more tags (called “Labels” in Pivotal).  The label feature allows you to place a story into one or more groups.  Using the interface that Pivotal Provides, it is simple to view all stories that contain a specific label.

An additional feature of Labels is what Pivotal calls an “Epic”.  An Epic is a group of stories that are connected via label(s), and the epic itself can be followed by people that may not be owners / requester of the independent stories.  An epic supports discussion and a description in it’s own space, outside of the stories.

Basecamp provides To-do “lists” that allow you to group To-dos together.  These To-dos within a group are controlled simply by placing the To-do into the To-do List.  A To-do can only belong to a single list.  A To-do List does not support separate followers, but does discuss independent discussion.

Task Prioritization

Pivotal Tracker supports prioritization at several levels.  First, all Stories fall within one of three main columns: “Icebox” for work that is identified, but isn’t priority.  “Backlog” for work that is current and is priority, but not actively being worked.  And “Current” for work that is identified and underway.  Additionally, Pivotal allows for sorting (via drag-and-drop) within each column, to add another level of priority.  So long as the users agree it is so, the stories at the top of the list would be higher priority than those lower on the list.

Basecamp does not appear to directly support prioritization, but you can drop in a label (from 1 to 10) to use to provide prioritization.  Alternatively, each To-do could of course contain a number representing the priority, or Lists could be use to

Task Completion

This topic, while it is worth calling out separately, truly is covered under the “Task Workflow” section above.

Miscellaneous

There’s a few things that are worth mentioning that don’t really fall into neat categories.

Pivotal for some time has had an open forum thread about supporting simpler pasting of images.  As it stands, if you want to post a screenshot for example, you have to take a screenshot, save the file, then attach the file.  The attachment process is simple / easy enough, but the feature has been requested (and is available in other systems) to simply take the screenshot and paste it into the discussion.

Basecamp suffers from this same shortcoming.  You can only attach image files, not paste an image in directly.

Pivotal’s flexibility can also be an issue, particularly if one of your collaborators is not on the same page as you.  If they happen to move stories around (changing the priority), these changes will be reflected in the project, even if it isn’t being used the way you would prefer.

Pricing

Each system uses a different pricing model, and this is where Pivotal gets the biggest knock in my book (note: after reviewing Basecamp, they make the same mistake in pricing).  Their pricing system is punitive to companies as they grow, which is exactly opposite of what pricing models should be.  Their pricing model is based on the number of collaborators (users that can actually do something.  “Viewer” users are free).  On smaller plans (they have a useful “Free” plan), you are limited by users, file storage, and private projects.  Once you get over 10 users, the storage and private projects are unlimited – it’s purely a matter of users.  In several of their pricing steps, the more users you pay for, the more you pay per user.   We are currently milking our price point for 15 collaborators, because the next step is 2x the price, but only adds 10 more users (effectively taking us from $5 per user to $6 per user, with no steps between).

Basecamp on the other hand charges by projects and storage, with much more tolerable pricing points.  While they don’t have a free plan, they do offer a free 60 day trial period.  We would likely fall in the $50 per month plan (whereas we’re paying $75 for Pivotal, and really do need to upgrade to the $150 plan).  Unfortunately, the features we need simply aren’t available in Basecamp, and so we will continue to use Pivotal – despite their frustrating pricing policy. Interestingly, their pricing is also punitive, but around the amount of storage you purchase. Their “sweet spot” is the $150/month plan, where storage is $1.50 per GB, but go to the “Unlimited” plan, and storage jumps to $6 per GB.

One of the many things that Alpha Channel Group offers to all clients working with us is using Pivotal Tracker (for no charge) with any projects. We have determined it is well worth the cost, and will gladly cover the cost of putting your projects on Pivotal Tracker, so that we can stay in sync on all of our work together.

Migrating a Single Site from One WordPress MultiSite to Another

Tuesday, October 28th, 2014

For Developers or Power Users

Warning: This article is designed for developers, or the technically experienced.  You should be comfortable working in databases, and utilizing FTP.

Overview:

We need to move a single site from within a WordPress MultiSite to another WordPress MultiSite.  The site is completely set up, including plugins, widgets, theme options, and other settings.

We want to preserve as much of the data as possible, without hosing the complete installation.

Note: for convenience sake, we used the following terms:

Source Install – the original site, that we are moving somewhere else

Target Install – the new site location, where the source site will be moved.

Steps:

None of the import / export that we have found tools cover this scenario, so we have developed a process:

  1. Set up the new site in your Target MU Install.  Take note of the site ID (prefixed in all of the database tables).  This will be referred to as the Target Site ID.
  2. In your existing Source Install, take note of the site ID.  This will be referred to as the Source Site ID.
  3. By accessing the database (for example, using phpMyAdmin), export the tables in your Source Install.  Only export those that pertain to the single site.  They should contain the site ID, for example “wp_3_options”.
  4. Make a comprehensive list of all relevant plugins being used in your Source Install – remember, there’s “network activated” plugins as well as “site-specific” plugins.
    1. FTP the plugins from the Source Install.
    2. FTP the theme from the Source Install.
    3. IMPORTANT: Prior to uploading the database, or trying to visit the site, it’s imperative that all of the plugin / theme files exist on the Target Install.
    4. FTP the plugins and theme to the Target Install.
  5. Open the SQL export file created from step 3 above in your favorite text editor.  Update all table names to reflect the Target Site ID.  Also change them to reflect the table prefix of the Target Install.
    1. Example: if the  Source Site ID is 3, and the Target Site ID is 5, and they both use the same table prefix of “wp_”, then you would find all table names and change them according to the following model:
      1. “wp_3_options” would be updated to “wp_5_options”.
    2. If the table prefix in the Source Install is “wp_'”, and the table prefix in the Target Install is “38921_”, then the example would look like:
      1. “wp_3_options” changes to “38291_5_options”.
    3. We are only using the options table as an example.  Currently there are 9 tables in a WP MU “site”, plus there may be additional tables depending on plugins or your theme.
    4. IMPORTANT: If you aren’t familiar with table prefixes, or any of this seems off, then we recommend you consult with someone familiar with WordPress, particularly Multi Site installations.
  6. In your Source Install, run the following query on your posts table to get a listing of all media / attachments that will need to be manually moved using FTP:
    1. “SELECT * FROM `wp_3_posts` WHERE `post_type` = ‘attachment’
    2. This will list all of your attachments.  This will help you ensure that you know all of the attachments that need to get moved.
    3. Check the source wp-content/uploads folder for a “sites” sub-folder. There should be a sub-folder that is named the same as your site ID, such as wp-content/uploads/site/3.   This would be the media for your specific site.
    4. Using FTP or rsync, move the contents of the uploads folder (wp-content/uploads/sites/3) to your target install (wp-content/uploads/sites/5).
  7. Import the SQL file that you have altered into the Target Install database.

If the site domain is changing, then the following steps may be required.

  1. Run the searchreplacedb tool on the Target Install database to update the site.  Be sure to only select the tables in your migrated site – not the entire database!
  2. After running searchreplacedb tool (available here), you may need to run it again to clean up certain paths.  These may be true for image folders, particularly if the new domain has a path in it, such as :www.mydomain.com/subfolder
  3. If the site domain is changing and you are getting 404 errors when you view the site, you may need to flush the rewrite rules. In a non-MU install, this is done by going in the dashboard to the “Permalinks” page and simply clicking “Save”.  In an MU installation, the only way we are aware of is to deactivate and reactivate the theme.

Test and Tweak

As with anything, some good testing is likely in order.  We have found that the most likely place for mistakes to happen is when running the searchreplacedb tool – be sure the new urls are correct.

 

Notes for future updates:

 

Import External Images plugin

Copy / FTP files from uploads/sites/[Site_id]

run SRDB2 to update images loading from proper site ID.

Conversion Rates – What is Your Site’s Job?

Wednesday, June 19th, 2013

We focus on conversion rate optimization with our clients.  We want the site to be effective at it’s job, and the best measure of that is to measure how often a visitor “converts”.

When you are building a site, it is important that you decide – up front – the job of your site.  Part of defining that is deciding what a “conversion” looks like for your site.  After all, in order to improve conversion rates, you need to first measure conversions.  And to measure conversions, you need to be able to describe what a conversion is for your site.

For an e-commerce site, that’s simple: a conversion is when someone purchases.  Maybe there’s a secondary, lower priority conversion of signing up for a newsletter, but the primary conversion is clearly for someone to purchase.

For other sites, it may be less obvious.  Maybe it’s completing a “Contact Us” form, maybe it’s signing up for a survey, maybe it’s something else.

And for other sites, there may be several different conversion objectives.  In a discussion with a non-profit client recently, it became clear that they had many potential conversions.  I suspect when we are done identifying them, we will end up with a list of somewhere between 8 and 12 different conversions.

It’s not until you’ve identified what a conversion means that you can then structure your pages to be effective.  Each page has a job, and that job should be to help move the visitor towards one of your conversions.  See how it would be difficult to design a page without knowing what it’s job is?

Once you’ve defined your conversions, you can then use Google Analytics to track conversions, and to calculate (quickly and easily) the conversion rate for each and every one of your conversions.  Then, using Google Analytic’s tools, you can see where people are bouncing, where they are maybe getting stuck in loops, or where you are losing them in the conversion process.

How To Make a Secure Password You Can Remember

Monday, January 23rd, 2012

Many people use lame passwords because hard ones can be difficult to remember. But that is dangerous. We have helped many people who have had an account hacked due to weak passwords. Does your password make the List of most common passwords?
(more…)

Who Owns Your Domain?

Saturday, May 29th, 2010

Your domain name is your online identity, so you should be certain you have ownership. Do you?

When you register a domain name through a registrar such as Network Solutions, GoDaddy, or Register.com, you go through a process of registration in which you are the owner of the domain name. Read More →

Whos Searching for You?

Saturday, May 29th, 2010

(by the way, we can tell you)
Searching for You

Right now people are looking for you. It doesn’t matter what you offer, the fact is that somewhere someone is searching for you. Now. The question is: Are they finding you? Read More →

Converting Visitors

Saturday, May 29th, 2010

Converting Traffic

Converting visitors isn’t rocket science, but it’s close. Look, the average conversion rate for websites is a pathetic 2.6%. Like all averages, this includes the high (catalog sites convert at over 6%) and the low (electronics: 1.1%). (Note that these numbers are likely skewed, because the source is a high-end Website Analytics company who’s customers are big-budget companies). Read More →

Design for Scaleability

Friday, March 26th, 2010

What a mouthful. What does this mean, anyway?

A Case Study

We were involved in a project. A fairly involved e-commerce site on a shoe-string budget. The site was designed using ASP and Microsoft Access, and was run on a shared server. The owner quickly realized that the site needed to be moved to a local Read More →

Do You Know Who’s Searching For You?

Tuesday, March 23rd, 2010

Right now people are looking for you. It doesn’t matter what you offer, the fact is that somewhere someone is searching for you. Now. The question is: Are they finding you? Read More →