Request Demo
6 min read

3 Sprint behaviors to improve delivery predictability

Sprint goals make organizational goals happen


Scrum is one of the most popular Agile methodologies that teams utilize. The regular cadence of planning and delivering in Sprints is well suited to today’s pace of innovation and the need for adapting to changing market conditions.

As organizations outline their yearly or quarterly goals those longer duration goals ultimately filter down and drive the focus of shorter duration sprint goals. Over the course of a series of sprints, the work teams do should be advancing the organizational goals. And it’s at the sprint level where the most impactful and least costly course corrections can be taking place to adjust priorities or scope to keep organizational goals on track.

To use an analogy from the sports world, an organizations quarterly or yearly goals are like a marathon. They cover a long distance and take a long time to accomplish…they take endurance. And if you’ve ever contemplated running a marathon, you’d have learned quickly that the first piece of advice is that running efficiency is key. You should focus on running form and that every footfall should be strategically placed to maximize efficiency.

In a similar way, we have learned that there are 3 key behaviors related to efficiency that improve predictable delivery in sprints.

Commit to Capacity

Ambition is awesome but when it comes to committing to a sprint backlog it’s always best to commit to capacity based upon what a team has demonstrated they can get done historically. For example) if your team has completed on average 55 story points of work each sprint for the last 3 sprints, you should almost certainly commit to 55 story points for the next sprint. When you do, the benefits include:

  • Reenforces a culture that the team is expected to set and hit realistically achievable goals

  • Improved focus on a prioritized backlog. When capacity is treated as a precious commodity to hones focus on prioritizing the most valuable work first.

  • The rewarding feeling of accomplishment teams get seeing all the work get completed. Knowing they have awesomeness to show at their sprint demo

But what about “stretch goals” you ask? They are great! We would just recommend that it’s better for a team to complete everything and bring new stores into a sprint than to not complete things and continually roll stories over. If that happens regularly it will be reflected in the historical delivery data and will inform the next sprint commitment (which will be higher).


Using swarming to limit WIP

Swarm on Issues

Swarming is an awesome concept where 2 or more team members will work together on a single issue (i.e. imagine them “swarming” around the task like bees in a hive). By itself, this approach has amazing benefits with respect to team building and feeling shared responsibility that are hallmarks of high performing teams.

I’m sure that many of us can think about sprint demos where teams point to their sprint backlog and all the stories that are “almost but not quite done”. The reality is that 1 done story is more valuable than 5 “almost done” stories because you can’t release those to customers. Swarming mitigates this and also serves to natur ally limit work-in-progress (WIP).

Sometimes we see organizations hesitate to try swarming for a variety of reasons. Here’s a brief rubric you can use when advocating to try swarming (because we’ve seen that once teams try it they see the benefits quickly)

Refrain Counterpoints of encouragement
“Our tasks can’t be broken down and shared” Breaking work down is a skill that is worth developing. If you are the advocate for swarming offer to help look for seams to split the work apart at. Writing tests is almost always an option.
“Our tasks require specialize skills and it’s not efficient to collaborate” This is a perfect opportunity for share knowledge and cross train. Don’t these specialized team members want to be able to take a vacation without getting a frantic call if something blows up only they can fix?
“Swarming will slow us down” Done work is more valuable then in-progress work. Make the point that too much work is getting started but not completed, and thus not in front of customers.



Make testing everyone's job!

Never say “it’s done but in QA”

This point is a related corollary to the point about swarming but deserves to stand on its own. If I had a nickel for every time I heard the refrain “this is done but it’s in QA” I’d have a lot of nickels. At one point we contemplated treating this phrase as a reason to contribute to the organization’s swear jar. This is by far the most recurring sentiment that reduces the power of a cross-functional team and diminishes the view that the ultimate measure of their collective success is fully completed work. It’s impacts morale when product developers express that their part is done and now all they can do is powerlessly stand by and wait for testing….Um, NO! If you can write the code you can help test the code.

If you’re hearing this phrase a lot we’d encourage you to step back and take an honest look at your end-to-end testing strategy. I’d lay odds that you already know the things you’d like to do to improve testing flow. Investing in testing is one of the most valuable things you can do to increase both quality and delivery predictability and speed. Here are a few strategies that have an immediate impact and can grow over time:

  • If you don’t already, start requiring unit tests on new feature code. The code is “new” and should not have constraints of legacy code which may not be built for testability.

  • Similarly, do the same on all bug fixes. The fact that you are fixing a bug means the area of the code is important and warrants the effort and has needs for testing. Be realistic about what can be accomplished. The goal is to incrementally add coverage. Every little bit helps.

  • Use testing as a starting place for experimenting with Swarming. Initially, the team will likely be mostly sharing knowledge of testing processes and accessing environments but it won’t take long before developers are proficient. And better still, they will also start to see how the skills they develop while testing help make them better coders. Before picking up the next issue to start new, they should ask what they can do to get an active issue completed.


Hakkiri Helps You Deliver Software Predictably™

Hakkiri empowers software organizations with our Continuous Clarity Engine™ to deliver products with speed and predictability. Our platform’s deep analytics surface insights that go to the core of what limits the ability to predict the completion of software deliverables. We know these problems and that it’s the things organizations do with diligence week-in and week-out that have a huge impact on success. We hope we’ll see the same when adopting these Sprint behaviors.

Stay tuned to our blog as we continue to discuss more topics that aim to make delivery more predictable. In the meantime, check out our product page to learn more about how our platform can help you.



James Smith

Written by James Smith

James Smith is a co-founder of Hakkiri. With over 20 years in technology he has been instrumental in numerous transformative initiatives as an engineer and executive. As the Senior Managing Director of Engineering at Eze Software Group, James brought 3 legacy organizations, spanning 350+ people at 7 sites around the world, together as a unified team. He guided process modernization and technology adoption to enable the business to move into the cloud. These experiences have given him deep insights into organizational change and how the culture of technology teams can impact results.