What is most crucial to consider when planning coding sprints?
By Massimiliano Genta and Klay Ketelle
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. They regularly outperform 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.
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). Sprints are really 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.
Planning a Sprint:
Sprints are so seamless due to the fact that they are meticulously planned, as to ensure no hiccups will delay your 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.
Sprint goal:
Ultimately, what will determine a successful sprint? What are you looking to accomplish? Goals should be clear, and ideally, “SMART” (Specific, Measurable, Attainable, Relevant and Time-Bound).
Sprint backlog commitment:
Team members will decide which items, that are currently backlogged, will be completed during the sprint.
Review product roadmap:
A pretty standard expectation, 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.
Verify alignment:
The backlog and the 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?”
What to be prepared for when planning a sprint?
For one thing, the key to a great spring 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. Albeit potentially annoying, these types of situations are not going to go away, and if it is important enough to be added with little planning, it’s best to take it seriously.
Technical debt:
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.
Developer empowerment:
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:
- “leading by example by demonstrating commitment to the work;
- exhibiting concern for the well-being of software developers;
- soliciting software developer participation in decision making about project-related issues;
- coaching software developers to be self-reliant in seeking solutions to problems; and
- keeping software developers apprised of broader issues that might affect progress on the project.”
In closing, when it comes to coding sprints, the old additive “failing to plan is planning to fail” really reigns true. Sprints can be an immense resource to the efficiency of your team, but only if you are able to prepare properly.
Extra Resources:
