We know our sprinters come from many different schools of development methods. With this in mind we wanted to make sure we made the product as flexible as possible to address many different types of users, yet still carry our core values. We have had sprinters ask how to track sprints in Sprint.ly before and we created this walk through. We wanted to create a video to help demonstrate the power of the tagging system built into Sprint.ly and to show step by step how to track a sprint. You can view it here.
Hello, my name is Chris Forrette and I’m the newest engineer on the Sprint.ly team! I’ve been writing code and making websites for almost 15 years now and this is my first foray into the startup world, after spending most of my career thus far in the agency world, and I’m really excited about jumping right in with Sprint.ly working on frontend and backend development.
I met Joe Stump almost a year ago now, after an introduction from a mutual friend of ours, an awesome developer/nerd-type by the name of Chris Lea—and I must admit, I was pretty smitten with Joe right off the bat. A lot of things that we discussed really resonated with me—both personally and professionally—and that’s a rare thing to stumble across. The timing wasn’t right back then, so I ended up spending some more time in the agency world. I kept in touch with Joe, got beers with him once in a while and I eventually got to a point where I really needed a change so I starting talking to Joe about working together again and here I am.
For me, joining Sprint.ly mostly boils down to one thing: quality.
Coming from an agency world, I tried to be as smart about my work as possible, but the fact is that it would rarely live longer than 6 months to a year or so. The things that I would spend night and day working on and poring over would inevitably get tossed out the window when whatever coinciding marketing campaign ended. I’m looking forward to really digging into my work, perfecting my craft, using my abilities to help Sprint.ly forward in the best way possible, and having that effort be meaningful and worthwhile.
Joe and the team here at Sprint.ly are all top-notch folks and it’s already been a fantastic experience to be in the same room with them. The team is continuously collaborative, easy to work with and ego-less, even though the breadth of experience and knowledge here could almost justify it. I’m looking forward to absorbing as much as I can from the fine people around me, while hopefully complementing the dynamic with my own background.
I think these types of characteristics in Sprint.ly—or any workplace for that matter—will pay out in droves. The people behind the product will continuously grow, the product will continue to become better and better, and it will hopefully make the lives of our users better as well. It’s a win-win-win situation.
We at Sprint.ly would like to issue a public apology to our customers. We haven’t delivered the very highest quality experience that you all deserve. I won’t get into the specifics of what got us to this point, but I do want to go over what we’ve done about it and what we plan on doing as we move forward from here.
Today we launched the culmination of close to 10 people-months of work. We’ve been heads down for nearly 90 days working under the hood of Sprint.ly’s frontend (FE). Sprint.ly’s FE is a complicated beast. It makes up the majority of our codebase at this point. To complicate matters further, we built it out before things like Chaplin or Thorax existed, which has resulted in us rolling a lot of that ourselves.
But not any more. Today’s release includes the following under-the-hood updates that will enable us to continue refactoring efforts with a greater degree of confidence and should greatly tighten up your overall Sprint.ly experience.
What all changed?
- We moved to Bower and set up a package.json for the various NPM modules we use to compile our FE code.
- We’ve updated all of our core libraries to their latest versions. This will let us leverage, amongst many other things, the event and view management in Backbone 1.0.
- We’ve found, and fixed, a major bug in how we use requirejs. This shaved about 1.8MB off of our compiled JS builds.
- We’ve moved our item collections over to use Backbone filtered collections. This little package ensures that all of your product’s items are in the appropriate column, under the appropriate parent, etc.
- We’ve dramatically increased test coverage on the FE. We now have almost 500 unit tests and over 2 dozen functional tests. We’re using Mocha+Chai on the unit test side and Selenium’s web driver tests on the functional side.
- We’ve fixed 279 bugs in the last 90 days. This is a combination of bugs related to our refactoring, bugs we found while writing hundreds of tests, and bugs that you all have reported.
- We diagnosed and fixed a number of FE performance issues.
- We’ve consolidated our FE automation into Grunt, which allows us to leverage a lot of great work from others, including source maps.
- We now require all FE pull requests to have unit test coverage and, if it makes sense, a functional test. FE unit tests are now automated via CI and, soon, we’ll be adding our functional tests to run against staging.
- We dug into TraceView’s advanced features, including RUM, and instrumented our BE. This lead to a number of fixes and speedups for our API users and our AJAX requests.
Now that we’ve cleaned house and laid the foundation for further improvements, we’ll be working on a number of further improvements.
- We’ll be moving to a data bindings framework, likely Thorax, and breaking down our “fat” render methods in Backbone.
- We’ll be combing through how events are sent and handled by our various views and fixing anything that looks out of whack.
- We’ll be working to expand our browser coverage.
- We’ll be fully implementing GetSentry’s reporting for the FE now that we have source maps.
- We’ll be reimplementing Caliper.io now that we’re on Backbone 1.0. If you haven’t seen Caliper.io, check it out.
This has been a huge learning experience for us at Sprint.ly. We wanted to say thanks to a few people who’ve helped us immensely along the way, in particular: Tim Koschützki, Sam Breed, and James Burke.
We hope you enjoy the improvements and, as always, please let us know if we can be helpful.
Yesterday I tweeted out that Sprint.ly was looking to diversify our applicant pool and was actively hiring developers (please email me if you’re interested in hacking with us). If you’ve been following, or engaging in, the conversation around diversity in technology and software development, you probably have a good idea of what the responses looked like. I don’t want to spend time covering the robust body of research that clearly demonstrates why diversity in the workplace is good for business as others have covered it many times in many ways much more eloquently than I could ever hope to.
But I do want to talk about this notion that you should always hire the very best developers and only the very best developers whenever you need to hire a developer. To sum up my opinion on this subject simply, this approach to hiring is akin to premature optimization. At Sprint.ly, we believe that experience and background are just as important, if not more so, as programming skills, which is why we’re putting effort into creating an applicant pool that is as diverse as our customer base is.
Why? There are a few reasons, but I’m going to first start by showing you a map of all the fine people who have been kind enough to give Sprint.ly a shot.
I’m extremely proud of the fact that we’ve built a product that resonates with people around the globe. This map, more than anything else, has made it abundantly clear that, to be successful longterm, Sprint.ly needs to embrace diversity in the workplace. I’ve gone so far as to set a goal that Sprint.ly have one employee on every continent.
Because our customers deserve the very best service and product. Delivering fantastic customer service and designing a great product require a tremendous amount of empathy. Empathy requires context. Context requires experience. No matter how hard I try, as a middle class white male from the US, I’ll never have the context or experience to fully empathize with women or people who grew up in dramatically different cultures or have had to grow up on the receiving end of bigotry.
In addition to basic gender, cultural, and ethnic diversity I also strongly encourage companies that I advise to diversify both skill level and skill sets. One founder that I was talking with about recruiting said, “Huh, you have a much different approach to hiring than everyone else I talk to. It’s much more holistic.”
Early stage startups are notorious for requiring employees wear many hats. If you go all in on top 10 CS school graduates, you’re likely going to find your sales and marketing funnels are empty, basic user documentation and on-boarding is missing, and customer development is lacking. Very few early stage startups legitimately need to follow this course, but I see almost all of them attempting to. I’m not sure I can think of a more anti-lean approach to building a team.
What do early stage startups need? They need a diverse set of experiences, skills, and backgrounds to cover all facets of product development at once with almost no resources. Approaching the complicated, multi-faceted problems of early stage startups with a homogenous team simply doesn’t seem like a very sound approach to us at Sprint.ly.
If you’re interested in employment opportunities at Sprint.ly, please do email me!
We have launched a new YouTube channel. We will be posting an on going series discussing how to use Sprint.ly. Beginners and pros can learn something from this series. Stay tuned and share the channel throughout your organization as a training tool. We look forward to bringing even more content to you about the world of project management. Please check out the new YouTube channel and let us know what you think!
It’s always so difficult to write about yourself in a blog. So I will just start this off with a, “Hi, my name is Donald Harris and I like working with creative people!” I would like to give you a little bit of my background and then tell you why I decided to join the team here at Sprint.ly. I have been in the IT industry for over a decade, with the last few years focused on project management. I have managed large and small teams of engineers and each company has had its own method for me to follow. I started using Sprint.ly at my last engagement and quickly became a champion for it inside that studio. Since then I started using Sprint.ly personally for small side projects and just began to really like it. So on the surface you could call me a fan.
Now that you know where I come from, let me explain to you some of the main drivers for joining Sprint.ly. Almost every project that I have worked on has had its own form of project management. At the beginning of each project they always start out with timelines and estimates that never work out. We would end up abandoning the time estimates and just push hard to make dates. Once I found Sprint.ly and understood how it handled estimations I wanted to know more about the theory behind it. From there, I started looking into the background of Sprint.ly, and found the tattooed, outspoken, and all inspiring Joe Stump. Not to come off as a kiss up, but I like working for people who are trying to buck an industry trend…. especially a trend that caused me pain in the past. Those are the main drivers that got me to join Sprint.ly, I can’t wait to help more people come to know Sprint.ly. And now that I am the Sprint.ly Evangelist, I will be doing just that! Expect more video tutorials, guides, and discussions around Sprint.ly and project management theories and practices. Now go get stuff done!
People are bad estimators. There is a really great overview on Quora about how and why we get estimations wrong. At Sprint.ly, we don’t estimate in days, but rather let the app tell us when we’ll be done.
Our saving grace against bad estimations is that people tend to work consistently over a long enough time frame. This is especially true across teams of people. Given a team and a series of quarters, we tend to deliver the same amount of work over the same amount of time. Sometimes I’ll be doing more work and Dave is off at a conference or two. A few months later, I become distracted with purchasing a house, so my productivity slips. These things are tumultuous in the short term, but they even out in the long term.
Using the “people are consistent in big groups over time” approach, we can use software to determine when things will likely be finished. We do this by calculating a rolling average of work that the team has finished over the past 3 weeks. We distill this into a rough estimate in the timelines view. We show you which tickets the data suggests you’ll finish at 7, 14 and 21 days out. These are powered by estimations of complexity (aka the t-shirt sizes) that each card has. The more tickets that are estimated, the better the predictions will be.
Using the data available to us, we can make predictions with some degree of confidence. In short, we’re likely to ship as much this week as we have across the past few weeks. That’s why we’ve dropped gut-based estimations in favor of data-backed prediction.
One of the things we’re constantly working on are ways to improve our UI around sorting and prioritizing items. A common pattern is the desire to move items to the top or bottom of Someday and Backlog.
Over the weekend we deployed a small update to the gear menu on our item cards. There are two new options: “Move to top” and “Move to bottom”. Each, with a single click, will push the item to the top (or bottom) of its current column if it’s in Someday or Backlog.