Let’s start this off with a scenario: say you’re a project manager for Dropbox. You have a large team you’re leading, with a Jr. Dev on your team. She regularly outperforms everyone, taking assignments and finishing them swiftly and with little errors. This developer burns down significantly more story points than other team members because these points were perfectly aligned to her level of development knowledge and expertise. At 3x the amount of story points completed, she is essentially doing more work than other team members, Sr. Dev’s included. If teams had more consistent, reliable ways of creating work and sharing value amongst team members, then situations like these could be readily avoided. Well, a solution is available, and has been producing results teams and managers are satisfied with - coding sprints.
Coding sprints are one of the best ways to improve software development consistently and at a good pace, without making incredibly big changes all at once. This article is going to answer some questions one may have about coding sprints, how to plan them, and their relevance.
Coding sprints are assigned for anywhere between a week and a month, and go about completing an assigned set of tasks, generally for updates to a tool that don’t require a new product feature rollout (maintenance mostly). Coding sprints are efficient, largely due to the fact that teams aren’t biting off more than they can chew. This means less debugging and less granular changes, creating efficiency for developers and no new changes or major delays for active users.
Coding sprints are so seamless because they are meticulously planned, as to ensure no hiccups will delay the progress. The goal isn’t to fix every issue simultaneously, as this would be simply inefficient. The goal is to find what areas of the product have a higher priority in terms of being fixed first, and work through these lists of corrections one by one, in terms of relevancy.
Ultimately, what will determine a successful coding sprint? What are you looking to accomplish? Goals should be clear, and ideally, “SMART” (Specific, Measurable, Attainable, Relevant and Time-Bound).
Team members will decide which items that are currently backlogged will be completed during the coding sprint.
The owner of the product, scrum team or both will ensure the end goal of the product; features, updates, functionality that are supposed to be added based on market trends or user preferences.
The backlog and roadmap are two separate entities and need to be worked through to get properly aligned. Project owners should be asking themselves “do backlog items meant for the sprint support the overall product roadmap?”
For one thing, the key to a great coding sprint is being able to roll with the punches. A problem that may arise out of nowhere, whether unforeseen or a request from higher management, has to be dealt with ease and utmost consideration.
While coding sprints significantly eliminate the idea of debugging immense code or code refactoring, it is inevitable that these instances will occur throughout the process. Making the debt known to the team, determining how much of it can go unworked or delayed, as well as bringing this debt into the sprint planning meeting are a few ways where technical debt can be alleviated during sprints.
Above all else, much like the beginning of the article, ensuring that developers are feeling seen and working towards a larger goal is essential in and out of coding sprint situations. Likoebe Maruping, Professor of Computer Information Systems at Georgia State University, says that managers have every opportunity, moreover responsibility, to make sure their teams are working efficiently, “[t]he essence of this style of leadership is that it focuses on delegating decision-making authority and inspiring confidence in subordinates’ ability to deal with work-related challenges.” Empowering these individuals through leadership takes form in 5 key behaviors that Professor Maruping lays out:
In closing, when it comes to coding sprints, the old additive “failing to plan is planning to fail” really reigns true. Coding sprints can be an immense resource to the efficiency of your team, but only if you are able to prepare properly.