Sprintly

Compare and Contrast: Sprintly and Pivotal Tracker

PTvsSPPivotal Tracker is a pretty popular cloud tool for managing agile product development, and while there are many things I like about it, I have also been messing around with Sprint.ly since I heard the CEO, Joe Stump, speak at a product management event a few months ago.  I compared and contrasted a few aspects of each tool and below are some of my thoughts.  Note:  This is by no means a comprehensive review of either product.  I’m not using either of them for production work at the moment, so I don’t cover things such as integration with source code repositories, APIs, etc.  The perspective I was most interested in was that of a product manager creating and managing high volumes of user stories, and trying to do so efficiently.

Screen Real Estate:

The first major item of note is that Pivotal Tracker uses the full available width of the browser screen, while Sprintly does not.  I can debate the merits and drawbacks of both choices, but I tend to prefer Sprintly’s approach because I believe the noise ratio is much higher in the Pivotal Tracker view.  The more information you see on the screen, the harder it is to find what you’re actually looking for.  On the other hand, in a tool that gets heavy use, I find getting used to the interface and using search frequently can help overcome that issue.

Terminology:

Pivotal Tracker uses the term Icebox for wish list items that may or may not end up being worked on, while Sprintly uses the term ‘Someday’ for those items.  New stories are added to these categories by default.  Pivotal Tracker uses Story Points (0, 1, 2, 3) for estimating, while Sprintly uses what it refers to as T-shirt sizes (S, M, L, XL).

Working Views:

Both products have what I’ll call an “abbreviated card view,” which lists user stories in columns according to the phase each story falls into.  These views would be the place I’d likely spend the most time in creating and managing user stories.  This is where you can add stories, estimate them, shuffle them from one phase/state to another, and start or complete them.

In Pivotal Tracker’s Organizer view, the default phases are Current, Backlog, and Icebox (you can add ‘Done’ and ‘Epics’ if you like – I added ‘Done’ to make the comparison with Sprintly more consistent).

PT1

Pivotal Tracker ‘Organizer’ View

In Sprintly’s Items view, the default phases are Someday, Backlog, Current, Complete, and Accepted, though Sprintly’s view does not display all five columns at once.  Instead, a banner bar above the columns that implies progression through phases acts as a filter to display the two most relevant phases.  Note the ‘Triage’ label that is highlighted in the image below displays the ‘Someday’ and ‘Backlog’ queues.  Were I to click on ‘Underway,’ I’d see the ‘Backlog’ and ‘Current’ queues.  ‘Pending’ displays ‘Current’ and ‘Complete,’ and ‘Done’ displays ‘Complete’ and ‘Accepted.’

Sp1

Sprintly’s ‘Items’ view with ‘Triage’ phase selected

One key difference in layout of the views is that Pivotal Tracker displays its columns in what I think of as reverse order of completeness (Done, Current, Backlog, Icebox).  Sprintly displays the columns in order of completeness (Someday, Backlog, Current, Complete, Accepted).  Sprintly’s order makes more sense to me because I am accustomed to reading/working from left to right.  This is probably a matter of personal preference, and Pivotal Tracker may assume that most time is spent in the ‘Current’ category, but I would argue that more time is spent in the Someday/Icebox and Backlog categories.  Once stories are created, estimated, and moved into the Current phase, I’m interested in monitoring progress, but am probably doing less data entry.  Sprintly does have a 3-column Dashboard view that can be compared with Pivotal Tracker’s default 3-column display, but  the central categories (Backlog, Current, Complete) are still displayed in reverse order as compared to Pivotal Tracker’s.

Inline Editing:

Both tools offer a lot of inline story editing functionality directly from the views described above.  Stories can be estimated, they can be dragged and dropped (or moved by other means) from one category to another, and they can be started or finished.  Tags assigned to stories can be clicked to quickly apply filters.  The images below show the functionality for both story cards.

Pivotal Tracker Inline Story Editing

Pivotal Tracker Inline Story Editing

Probably the single thing that bothers me most about the Pivotal Tracker UI is the placement of the tags assigned to stories.  If you add tags to stories, they appear ahead of the story text itself, which I think is very distracting.

Sp2

Sprintly Inline Story Editing

Sprintly places the tags after the story text, which makes it much easier to read the primary story text.  I do think they could improve on the question mark icon for estimating stories, though.  A question mark means ‘Help’ in practically every context on the Internet, so it’s not at all obvious that this is where you click to estimate the size of the story.  Given that they use T-shirt size for estimating, a simple solution could be to replace the question mark with the outline of a t-shirt.

Pricing:

Pivotal Tracker wins hands down on pricing.  Sprintly charges a whopping $14/month/user, while Pivotal Tracker has much more reasonable pricing plans.  First, they offer a free plan for a single user that doesn’t need collaborators or many projects.  Sprintly has no free plan.  Additionally, Pivotal Tracker has a variety of packages that allow multiple collaborators and multiple projects for very reasonable fees.  The Startup L package includes 7 collaborators and 10 projects, for $18/month.  7 collaborators on Sprintly would run $98/month.  That’s a huge difference in price.

Conclusions:

While both products do a great job presenting and organizing complex information in a relatively clean and intuitive way, I like Sprintly’s UI better.  It feels more natural and seems designed to narrow focus while presenting information in a logical and really pleasing way.  Besides just stating this was a main driver of the product itself at launch, the terminology and some functionality Sprintly has chosen indicates that they view the product development process as one that will include non-technical people (T-shirt size vs. story points; an Accepted state for stories).  I like this more inclusive approach to product planning and development.

Given that Sprintly has only been around for about a year and a half, and Pivotal Tracker has been around for about five years, I’m definitely impressed with what Sprintly has accomplished.  I’m the type of person that likes the underdog and wants to throw my support behind companies and products I truly love and admire.  However, for many users, price is going to be a deal-breaker.  When you can get essentially equivalent or even broader functionality with other more mature tools, it’s hard to justify such a large price differential unless, perhaps, those other tools have truly horrible user experience, and in this case, they don’t.  Perhaps as Sprint.ly grows they’ll be able to offer different pricing packages that make it more reasonable.  I hope they will, because I’d like to see them succeed.

First Impressions: Sprintly for Agile Product Management

Items View

Items View

A few weeks ago, I attended the first StartUp Product Summit in San Francisco, and I was really happy with the event.  I shared some thoughts about my favorite speakers after I attended, but since then, I’ve also been checking out the products some of those speakers make.  I’ve been kicking around an idea for a web-based service for a while now, and I thought I’d start to log some user stories for it with Sprintly, whose CEO was a speaker at the Summit.  As Joe outlined in his speech, there are a ton of products in this space, and I have experience with a handful of them (RallyDev, Jira with Greenhopper, OnTime).

First impressions are incredibly important when choosing software in a space where there are a lot of choices available, and my first impression with Sprintly is that they get it.  When I signed up for my 30-day free trial, it was very easy for me to create my first product and my first items, and I really love the UI.  It’s simple and clean, while still achieving a lot in terms of presenting a significant amount of information without overwhelming me with it. In minutes, I had 20+ items created, and though I haven’t yet done much with those items (I’m just too early in my own process), I did have reason to make edits after I created the items, and to reorder them.  Those basic functions in the Sprintly UI are implemented perfectly – intuitive in-line editing for every piece of info on my story cards, drag-and-drop re-ordering of items on the screen.  I can say without reservation that I’m really looking forward to further using the product, and I intend to upgrade to a paid account at the end of my trial.

That said, there are a few minor changes I’d make.  First, while it was very easy to set up my first items, I couldn’t tell immediately where they went.  That’s because Sprintly defaults to their ‘Dashboard’ view.  While I imagine I’d use this view more often later in the process, right now, I’m only creating user stories, so I’m working entirely in the ‘Items’ view (Item being the generic top-level data object that acts as a user story).  It would make more sense in the on-boarding process to dump a new user into the Items view first, since all new items fall into a queue called ‘Someday’ as soon as they are created, and this queue is only displayed in the items view.  The Dashboard view only displays items that are in the backlog, currently being worked on, or are completed, and that’s the disconnect.

As soon as I figured out that’s where I needed to be, though, I’ve had no issues with navigation in general.  I’ll also add that the other main views offered in the app seem intuitive, though I don’t yet have useful data to look at.  When I load the screens, they don’t show me my items because I haven’t put any of them in the backlog or estimated them, or begun working on them, so things like velocity and the team cadence don’t yet have data.  The other thing I’d recommend is that Sprintly place their logo on all the screens.  As you can see in the associated screenshot, the logo is nowhere to be found on a working view, and it’s a really nice-looking logo.  The little sprinting man is perfect for dropping into a page header unobtrusively, and they do use it as a sort of ‘loading’ indicator when you switch from one view to the next, but it goes away after your screen loads.

A final note is that while I had the opportunity to hear Joe Stump speak, and that piqued my curiosity about the product, I also really like what I’ve found online.  In the company’s blog, Joe explains how they made some recent major performance improvements, and talks about his philosophy about the Agile Manifesto, and I really like his style.  It tells me that the company isn’t just making another product to track user stories.  They expose what agile means to them, how they use it, and lift the covers on some of their code along the way.  In terms of first impressions, after spending maybe an hour with the product, I’m walking away thinking this is the kind of company that wants to contribute to a community, and if Sprintly can leverage that and bake it into their culture and operations on an on-going basis, it may be a valuable tool in their quest to collapse  and consolidate what is now a pretty heavily segmented market.  I think the tech community is made up of people that largely want to support other people that give back, and this is a fresh new start-up that I’m happy to get behind.