Announcing the New Voltron in Agile Software Development: Sprint.ly and Quick Left

Those who’ve worked with us at Sprint.ly - as customers, colleagues, and partners - know that we’re committed to our craft. We enjoy pushing the envelope on UI/UX, development methodologies, and technology. At times, this has meant needing to pull in specialists who are working at the very edges of their field to help us deliver. This is how we met Sam Breed and the Quick Left team in Boulder, CO.

Sam is a core contributor to Backbone, which lays at the foundation of our frontend architecture. His contributions to our recent performance refactor have dramatically improved the responsiveness of our application. After completing this project, two things were clear to me:

  1. Sam and the Quick Left team are consummate craftspeople. Delivering quality code and actionable advice took precedence over their bottom line.

  2. I wanted to spend more time working with Sam and the Quick Left team.

Sadly, I couldn’t recruit Sam and he couldn’t recruit me. This mutually sad realization, coupled with Sam’s confession that Quick Left was keen to start building their own products, led me to invite Sam out for beers.

I had an ulterior motive, though, which was to propose that we combine Quick Left’s chocolate with Sprint.ly’s peanut butter. We were building a great product, which Quick Left and their clients used, and Quick Left had an enormous engineering team ready to be aimed at the treasure trove of products swirling through our collective brains.

When our CSO, Matthew Work, first heard the idea he said simply, “That’d work.” Matt’s background at Pivotal Labs running Pivotal Tracker gave him great context to see that this symbiotic relationship had real potential.

Today I’m enormously proud, and exceedingly humbled, to announce that this potential has been realized. Sprint.ly and Quick Left are now one. We will operate offices in San Francisco, Portland, and Boulder. Our mission is to deliver great products - our own and our service customers’ - using the very best technologies and development methodologies available.

Wow. I am excite. Much coding ahead.

Cheers,

Joe

Joe Stump
Founder, Sprint.ly
@joestump

P.S. You can read more about this awesome news, along with FAQs, on our homepage.

Sprint.ly’s New Pricing Model

image

Most companies in the business-to-business SaaS model work on a freemium model or a trial model. We are going to try both.

Gone are the days when you could make a simple software product that serves all customers the same way. We now have to design the whole product and the user experience around it.

These days, a complete product entails marketing funnel, onboarding, discovery, add-ons, and communication. Now we are trying to make a product that offers distinct benefits to different sized teams and people with different roles. Our design challenge is to create a product that can grow with the customer and retain them, while not being overwhelming at the start.

This complexity plays out in our pricing model as well.

We need a pricing model that gets us in the door, charges more as we provide more value to larger teams, and makes enough money to keep us in business!

So we’ve talked to our existing customers, former customers, and prospective customers and have tried to imagine and build a total spectrum product that addresses the problem of “graduation” - the movement of successful growing teams onto more enterprise- focused products.

Today, we’re happy to announce that we have launched a new pricing model. It’s sort of a hybrid between freemium (very small teams are free) and low-cost tiered plans, with high-value add-ons coming soon at most all levels.

We decided that our new pricing model must:

  • Have a free tier for small teams
  • Present compelling up-sell opportunities
  • Match price to value, and not be gimmicky
  • Encourage the adding of people to teams
  • Make sense for both makers and managers
  • Allow existing customers to retain old model if they prefer

We hope you love it. Let us know either way:

twitter: @sprintly​  / support@sprint.ly

Have some questions? Read some common questions from the Billing sections of our knowledge base

New Feature: Reports

image

Sprint.ly rolled out a beautiful new collaborative feature today called Reports. Reports is a great way to view items within one product, across all phases and in a grid format.

Features & functions available in Reports:

  • Pie Chart
  • Ownership Bar
  • Full Card / Minimized Card
  • Sort Columns
  • Filter by different item criteria
  • NEW! Filter by Date

Reports is available to existing customers who are on the $14 per person per month subscription plan and for new customers on the Medium and Large tiered pricing plans.

Also included with this Sprint.ly release is an important name change to the existing Items view. We changed it to the Organizer. It is the same great tool but now with a name that is more descriptive of its purpose!

We hope you enjoy it!

Sprint.ly Performance Update

Last week we launched a dramatic increase in performance for our front end. We are built on Backbone.js and, over time, our rendering times have slowed down. Luckily, using some of the great tools in the latest versions of Chrome and a few additional tools for instrumenting how the Sprintly frontend was performing, fixing it was dramatically easier than it would have been just a few months ago.


Analyzing the Refactor

After some initial testing of rendering times and analyzing performance data gathered with Caliper, we determined that the best way to get out from underneath lethargic performance with large item-sets was to rethink how item cards were being rendered throughout the app, with a focus on item columns. Item columns are containers for groups of item cards (stories, tasks, items and defects) and show up on the dashboard and items pages.


Item column views do *a lot* of heavy lifting in Sprintly, and since they were initially developed a myriad of features have been added, subtracted, balanced and adjusted, leading to optimizations for some scenarios but not others. We sped up item columns primarily by optimizing how item columns rendered and cached the individual cards that go into them—rather than re-rendering column contents when changes happen, cards are inserted, removed and re-rendered individually, leading to better overall performance everywhere item columns are in play.


Better Tooling

The new Flame Chart view for CPU profiling made it easy to spot and optimize areas in our app that needed a dose of micro-optimizations. Given that many of the performance enhancements focused on customers with the most items, relatively small improvements can have a big impact on the most intensive parts of the rendering stack: smooth scrolling / lazy-loading, resorting and switching between the dashboard and the items view.

 image


The notion of JavaScript and browser rendering “frame budget” was a focus of the performance refactoring and much of the speed improvements can from recognizing when the Backbone application was attempting to do too much during a given frame. Actions that trigger rendering/repainting, requesting data from local cache or from the API or binding events to the DOM are common culprits when trying to improve framerate.

 image


By using the timelines panel in the Chrome developer tools we were able to identify where bottlenecks were forming, and were able to move many rendering actions to be asynchronous, either by delaying them with a set timeout or a using requestAnimationFrame.


A big shout-out to Addy Osmani and his spectacularly titled blog post Taming The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools, which provided an excellent set of sign posts for wandering through the jungle of JavaScript heap dumps and CPU profiles.


It’s worth noting that while we were primarily measuring in the latest version of Chrome, there are good alternatives in the Firefox devtools, which we were consulting from time to time to make sure gains in one browser weren’t causing regressions in another.


Performance Monitoring and Measurement

We were able to consistently and accurate measure performance characteristics, which greatly influenced how we went about re-writing how item columns and item cards were being rendered to address these framerate, load time and rendering concerns.


Here are some of the results that were measured using Caliper from before and and after the performance release:


Before the performance refactor:

image

 

After the performance refactor:

image

 

Following the performance release, average rendering time was decreased on average of 30%, with an 11% decrease in 90th percentile rendering time and a 6% decrease on the median response. We’re going to continue measuring and quantifying frontend performance—and still have more speed improvements in the works.


We’ve noticed palpable difference in performance and have been hearing the same from some of our customers already. Rob Munro, CEO and Scotch Aficionado of Idibon, told us “We stress-tested Sprint.ly over the last couple of days a few times with multiple people searching/browsing/editing all at once. It went really smoothly - thanks for the great product updates!!”


Let us know if it feels good for you too.


Thanks so much to Quick Left, our pals in Boulder who helped bring all this impressive JavaScriptiness together.


About Quick Left: Quick Left is a consulting agency of technologists and designers located in Boulder, Colorado. Quick Left specializes in building custom web and mobile applications through a transparent agile workflow process. Contact hello@quickleft.com for more information on project estimates, developer resources, developer training and UI/UX design. Follow @quickleft on Twitter.

Sprint.ly Closes Seed Financing Round

We are pleased to announce the closing of our Seed financing round.  The financing yielded about a million dollars in new money for Sprint.ly to expand marketing and hiring.

We’d like to thank Freestyle Capital, our long time supporters, for leading the round that included some of our mentors and friends, completely new folks from AngelList , and for the first time, a few actual, living, breathing, current customers.

When a customer buys into our round we feel especially gratified that their experience warrants backing our company and efforts. We care deeply about improving the way software gets made. When a customer gets it, we feel great. When they literally “buy in” we feel even better.

The tools for financing companies continue to evolve (AngelList, KickStarter, etc.) and increase the democratization of company financing. We enjoyed using AngelList to reach the Angel investor community; we can see that this is world-changing, and we love it.

Now we will put our noses down and our fingers back on the keyboards. Hopefully it will be several months before we have to do another pitch meeting!

New Sprint.ly Search Backend

Hey Sprinters! We rolled out a new search backend today. This big win with ElasticSearch will allow us to greatly expand our search features in the course of the coming months.

In the meantime, our new search offers you some great immediate benefits:

  • Items and comments are indexed within a second or two. This means searching for keywords and terms from newly posted comments, updated items, etc. will turn up results immediately.

  • The Search field’s type-ahead will also return ALL results. We previously returned the top 20 hits and this may have inadvertently caused confusion.

  • We’re also weighting certain fields. For instance, we “boost” title over description, which means items with “internet explorer” in the title will show up before items with that phrase in the description. Additionally, we’ve boosted Backlog and Current items over other items. We’ll be continuing to play with these weightings in the coming weeks.

We’re very excited about this first step towards expanding our search capabilities and look forward to rolling out more search features for our Sprinters.  

You may learn more from our knowledge base article. As always, please contact us at support@sprint.ly with any questions.

Sprint.ly Backlog Management

Managing your project’s backlog can be an unwieldy process when you’re facing a long list of items. At Sprint.ly, we are project managers as well and use Sprint.ly every single day to manage our long list of iterations, releases and internal projects.

We created this simple walk-through on how to effectively manage your project backlog. Keep in mind that Sprint.ly was built for many different styles of project management. What we show you here what works for our team. We encourage you to use the flexibility built into Sprint.ly towards a method that works best for you.

Outage Report

Today at 10:03AM Pacific we began experiencing an outage that resulted in a total of about 15 minutes of intermittent downtime. Our TraceView graphs show a clear MySQL anomaly.

image

We use Amazon’s RDS product for managing our MySQL needs and Sentry for tracking exceptions from Django. When we looked into the graphs and error reports we noticed MySQL was having disk space issues. Our first thought was we’d ran out of disk space on our DB server, but Nagios didn’t report any warnings about us getting close to running out of disk. Upon inspecting the RDS graphs we found something strange.

image

Our best guess right now is that some operation caused a large temporary table to be created at 17:00 UTC. Our RDS snapshots are scheduled for 13:30-14:00 UTC, our maintenance window is Tuesdays from 10:30-11:00 UTC, and our weekly full DB backups run on Friday at 16:00 UTC. This leaves us reasonably confident it wasn’t a scheduled maintenance issue.

Regardless, we’ll be taking the site offline tonight in order to dramatically increase the storage available on our RDS servers. Customers can expect about 30 minutes of downtime around 18:00 Pacific (1:00 UTC). Thank you for your patience and our apologies for any inconvenience this caused you!

UPDATE: We have double checked our cron jobs and confirmed none that run at this time. Additionally, no large API requests were sent in this timeframe, which also has special checks to limit data sent across the wire to mitigate abuse issues.

Welcomes Phuong Palmares to the Team

First let’s get the obvious aside – how do you pronounce “Phuong?” It is pronounced as “Foo-ung.” Most Vietnamese and oddly enough, Spanish speakers can pronounce this name without much ado. Saying “Foo-ung” while gesturing a waving motion with your arm helps. If that didn’t work, you can just go with F-O-N-G. I’m good with either.

I joined Sprint.ly this September as the Director of Customer Success. It’s a pretty big and exciting title that means that I get to be the voice of our customers. I have served the better part of the past 13 years serving customers. After college I started in customer service at a DSL provider, taking on the most frustrated of customers who called in and demanded to speak to the CEO. Next, I moved into electronic discovery and litigation software. I trained, supported, project managed the world’s top lawyers (usually pretty non-technical folks) and corporations on how to use keyword search, concept search and automation to cull down petabytes of data into the most relevant morsels. These are the most relevant files to be produced into a court proceeding and it was all done on our SaaS-based software. It was here at Discovery Mining where I worked for our Sprint.ly CSO, Matthew Work.

Earlier this year Matthew introduced me to Sprint.ly and Joe Stump. I found Joe to be this enigmatic and passionate data wizard dressed up in tattoos and pink Converses. His ideas and plans for Sprint.ly are clear and are real market differentiators. I also found the incredible combination of intellect, creativity and forward-thinking approach from the rest of the Sprint.ly team as a rare find. I knew I had to be a part of this spirited Sprint.ly team. It is this talented Sprint.ly team that is the core of Sprint.ly’s culture and success. It is the faces above who build, deliver and service the Sprint.ly product that we all use as an integral part of our own business processes.

I’m honored to be the voice of our dedicated Sprint.ly fan base. Some of you have already seen my name come through your email inbox in the form of check-ins, offers for help, or surveys. I am serious about being the voice of users and am here to be of assistance. Thank you for taking the time to respond to my emails and my surveys. They lay a foundation for the exciting new things that you will see from Sprint.ly. I promise.  

 

Sprint.ly Welcomes Nicholas Serra to the Team!
Hey, my name is Nicholas Serra, and I’m excited to be joining the Sprint.ly team! I’ve been coding for over ten years, having spent the last few of my career at a small startup in Ohio.
 
I’ve spent some time doing agency work, which leads me to say that working for a startup is definitely a better fit for me. I thoroughly enjoy participating in the continuing evolution and progression of a product. From chasing bugs to developing new features, making improvements and optimizations to a codebase is something that I take pride in.
 
I first used Sprint.ly almost two years ago to aid in managing my previous team. My impressions were very positive and I recall thinking that the Sprint.ly approach to handling task flow was very different and refreshing. My introduction to the Sprint.ly team occured almost a year later when I signed on to assist the team with bug fixes and small features. My experience with the Sprint.ly team is one of the main reasons that I’m so excited to be joining. I believe that it is especially important in this industry to surround yourself with people that are motivated and have fresh ideas. Fortunately, they are a group of very talented, creative, and easy going people who I very much enjoy sharing an IRC channel with on a daily basis.
 
On top of the team, Sprint.ly also happens to have an awesome and active user base. It’s these users that serve as motivation to me to continuously push out features and improvements to the system. Looking to social networking or direct customer feedback and seeing positive comments and constructive criticism is definitely a driver for me personally.
 
And of course, I just think that Sprint.ly is a useful piece of software. I’ve used far too many project-management type systems in the past with unfavorable results. Sprint.ly has been the right tool for the job for me on multiple occasions. I also really enjoy the fact that the team uses Sprint.ly to develop Sprint.ly. Improvements, features, and bugs are all tracked within the Sprint.ly project in the same way a customer would track their own product.
I look forward to working with the team full time to continue releasing features and fixes that improve user experience and Sprint.ly as a whole.