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


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


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


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.


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.


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.


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

Clever Features: Gmail

As I described in an earlier post, a product designer’s ability to anticipate user actions can result in the kinds of features that help a product to stand out from the crowd, or just plain make users happy.  Some of the best designs build features and interactions that are so smooth the user doesn’t even realize what’s in front of them.  Others pop out at you, like the brilliant Gmail attachment reminder prompt.

I send attachments via email all the time, and often I either get wrapped up in writing the email, or get distracted by something for a few minutes, and come back to finish and send it.  Inevitably, I forget to attach the file I’ve said I’m sending to whomever the recipient is.  Gmail has a great reminder feature that works by doing a quick scan of the body of your email.  If you’ve said ‘attach’ or some variation of that word, but didn’t attach a file, Gmail prompts you to ask if you mean to send the message without an attachment.

This is a really simple, yet really brilliant feature.  It represents holistic thinking about what a user does (or rather, doesn’t do), when interacting with an email program.  I have no inside knowledge as to how Google designs its features, but if I were to think of this feature in general agile development terms, I think it’s the type of requirement that would come of some in-depth discussions about user types.  I’ve said before that companies need to go beyond the ‘As a user, I want to …. ‘ user story, and instead dream up all the possible personality types they can.  In this case, had someone defined a “busy user dealing with regular interruptions,” or “forgetful user that writes really long emails,” they may have come up with this concept.  Of course, thinking about what people don’t do can be conceptually more difficult than thinking about the core use cases a program has, but it’s in coming at problems sideways or with some different perspective that features like this are thought up.

Defining Users in Agile User Stories

In reviewing a list of user stories for a large project recently, I was struck by how many of the stories started exactly the same way.  “As a user, I want to __________, so that __________.”

User stories are meant to be written in this format:

As a [role], I want to [goal], so that [benefit].

Role indicates the type of user or actor that will engage with the application.  Goal describes what that user wants to achieve with his or her interaction, and benefit indicates why they want to perform that action.  It’s just another way of stating ‘Who, What, Why.’  The idea is that a product owner speaks in business terms and phrasing requirements in this way helps the entire team look at the product from the business user’s perspective, not a technical perspective.  It’s the basis for user-centered design.  There is a pitfall that I see with this approach, though, and it lies in viewing users too broadly.

Most teams will be successful identifying a variety of types of users when the roles of those users are well-defined and distinct from one another.  For example, many software systems require administrators to set up accounts or manage internal settings that aren’t exposed to the everyday user of the system.  In this case, some user stores will begin with “As a user, I want to . . . ,” and others will begin with “As an admin, I want to . . . ”  This kind of delineation between roles is obvious, but when you consider the everyday user of the system, there may well be value in differentiating even further.

For instance, in designing an e-commerce website, you may end up with a better design if you consider that male and female shoppers have different behaviors, and high frequency purchasers will behave differently than shoppers that only visit the site once or twice.  Consumers that log in with an established account should have a more personalized experience than “guests” that don’t identify themselves by logging in.  Some people like to take their time and browse through many items, while others know exactly what they want and don’t want to have to navigate many levels deep.  For them, a strong search function might be all they care about.

There are a number of ways to leverage this kind of detailed breakdown of users.  Different UIs can be designed for different types of users, or you may instead decide to design for the least tech-savvy user you can imagine in the ecosystem of your application.  Whatever approach you take in the end, you will benefit from dedicating a session or two to defining all types of users you can think of.  It can also be useful to create a profile for each type of user as you identify them.  Some companies even give their “users” names.  A profile, which should be kept to a single page or less, can describe demographics, primary and secondary goals that user might have as they interact with the system as a whole, and a description of what you project they would like and dislike about interacting with applications in general.

Complexity Theory and Agile Methodologies

I spent the latter part of my time in my Master’s program researching complexity theory and the implications it might have on leadership and product/software development.  As I did my research, I learned that the principles of complexity theory are very well aligned with those of Agile development methodologies, despite the fact that Agile methodologies seem to have been developed with few, if any, formal ties to Complexity Theory (CT) or Complex Adaptive Systems (CAS).  I drew two key conclusions from my work.

1 – Those that recognized the need for new planning and management paradigms in creating great software did so largely based on their own common sense.  They weren’t reading about theory and then attempting to apply it.  They were simply experimenting with new approaches that worked because they represented reality better than their predecessors.

2 – The fact that Agile methodologies have become so prevalent and have been so successful in software development lends credence to the tenets of Complexity Theory.

Complex Adaptive Systems (CAS)

CAS are open systems that constantly adapt, and interactions and relationships between interdependent agents are considered more important to generating emergent knowledge than are the individual agents, or nodes in the network that describes the system.  Cause and effect are non-linear, and multiple structures, behaviors and influences may create significant changes in a Complex Adaptive System.  In many cases, output, or effects, become causes, and a very tangled relationship between input and output exists.

The agents in a CAS interact together and are adaptable, in that they can learn from individual experience, and be influenced both by other agents within the system, and by other pressures, internal to or external from the system.  Feedback loops in the form of direct individual experience and memory, and observation of interactions between other agents contribute to the constant adaptation of both the agents and the system as a whole.

A Complex Adaptive System does not require a controlling mechanism to direct the generation of output, and, in fact, the output of a CAS cannot be directed by a single controlling mechanism.  Emergence occurs naturally, as a result of the interplay between agents.  The nature of a Complex Adaptive System, defined by its adaptability, non-linear cause and effect, and organic evolution without a controlling mechanism all combine to make it complex and irreducible to its component parts.

Agents within a Complex Adaptive System are influenced by a myriad of things: other agents, outside information, pressures from inside and outside the organization, previous personal history, and the emergence of subgroups of agents within the CAS. These influences may cause one agent to respond one way, while another agent responds differently.  Those responses go on to influence both other agents, and the original agents themselves, as outcomes from what may be considered small changes spark new changes or die out.  It’s easy to imagine within a network of many agents that adaptation is impossible to control and the outcomes that emerge are difficult to predict.

Waterfall vs. Agile

Traditional methodologies are often referred to as “Waterfall” methodologies because they rely heavily on execution of a pre-defined and commonly understood sequential series of phases that make up the life-cycle of software development project.  These phases at a high level include planning, development, testing, and deployment, and a project goes through each of these phases only one time throughout its life.  A Waterfall approach relies on top-down, bureaucratic, command-and-control methods of leadership.  It uses front-loaded planning activities which aim to solidify the requirements early for a given software development project.  It can be cumbersome and inflexible, creating conditions in which adaptation and innovation are difficult, if not impossible, to achieve mid-stream while software development is underway.  For some, the Waterfall approach is viewed as too cumbersome and inflexible to keep pace with the demands of modern software applications and their end users.

Change, however, is inherent to the software industry, and customers, users, and development team members themselves often refine ideas as time passes, generate new ideas based on feedback and experience gained throughout the project development timeline.   They are constantly exposed to new approaches to feature functionality by virtue of their membership in the software industry.  This brings them in close contact to other products that may be wholly unrelated to the product or project in development, but which may offer relevant and valuable ideas that could positively impact their development efforts were there mechanisms that allowed for change throughout all phases of the project.

Modern development methodologies, which fall under the umbrella term of “Agile” methodologies, began to appear around the year 2000, and have proliferated in the decade since.  The defining characteristics of Agile methodologies include an inherent flexibility based on a highly iterative approach, where the least amount of planning necessary to understand a software feature is done as late as possible before that feature is built, and then it is immediately tested with end users.  This approach is repeated over and over throughout the software development life-cycle, and thus the end product can be seen as something that evolves based on increasing knowledge of the team, which consists of developers as well as users of the system.

Complexity and Agile

While Agile methodologies have become more and more popular over the past decade, critics believe that Agile approaches lack structure and discipline, and lesser quality deliverables may be produced as a result.  Agile development consists largely of a set of principles and somewhat standardized techniques that have evolved in practice more than they have been developed in theory or by research.  Some scholars believe this weakens the merit of the methodologies.  Agile methodologies are also more difficult to employ when working with distributed teams, especially those that cross time zones and cultures, because the approach relies heavily on frequent communication.

Despite these potential drawbacks to the use of agile methodologies, viewing agile approaches through the lens of complexity science adds value to the discussion.  For instance, iterative software releases managed on a frequent basis are principally aligned with the CAS concepts of adaptation and evolution.  The agile process that includes frequent testing and input from stakeholders maps to the CAS principle of feedback loops, and the more loosely structured environment found in agile teams aligns with CAS concepts of distributed control.

Supporters of Agile methodologies view software requirements themselves as dynamic and changing, and believe they are better suited to adapt to these changing requirements by employing a process that allows for and embraces change throughout the cycle of development.  Supporters of traditional software development methodologies take the stance that non-technical end users don’t necessarily know their requirements and need direction from developers, while Agile supporters believe neither the customers nor the developers know the full requirements of a system, and they must generate that knowledge together in order to arrive at the best possible solution.