<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=443149619225659&ev=PageView&noscript=1"> What to Do Between Sprints

We would like to email you valuable insights on software development and DevOps! (We promise not to stalk you or share your info)

 

What to Do Between Sprints

What to Do Between Sprints

Video Transcript

When we're doing an Agile implementation, which is typically based on the scrum framework, people always ask "Should we get a break in between sprints?", or "Hey, we want to take a break but what do we do during that break?" If you read and research on the Internet, there's a lot of ideas out there but there's three main courses: one is you don't take breaks. This is scrum there are no breaks. Everything should happen within the scrum.

Second idea is that we take multiple days: one, two days, three days in between sprints, and then there's a lot of creative ideas, like Mike Cohn's 6x2+1 idea where you do six two-week sprints and then you get one week which is really developers' or teams' choice of what work they're going to do.

All these ideas are great, but we have an idea that we think is best for implementing in a scrum environment. One idea is if you schedule your sprint demo and retrospective, say, on a Tuesday morning, don't schedule the sprint planning for the next sprint until the next day. This gives probably about a four or five hour afternoon where the team has some downtime to do whatever they feel is necessary.

A lot of people would think, “Okay, what is going to happen if we allow this short break? Is everything is going to break into chaos?" If you read the internet, it's “Oh my God! Things will break into chaos! Horrible things will happen! People cannot work in an unstructured environment!”

And what really will happen is a couple things: number one is the teammates will actually take time to consider the retrospective feedback. We have this retrospective and the team talks about it, but people need some time to go off and reflect on their own and think about what they would do based on feedback. The second thing is people may have had bugs that popped up at the end of the sprint or some technical debt that's really bothering them. Maybe they can go fix it, or do some research as to how they would fix it, and they can come into the sprint planning ready to make a recommendation.

Teams can do cross team collaboration. Maybe two teams say, “Hey I want to get into more of what you did. I want to see how you did that,” or “I want to talk about some things.” It's free time to get ready for that sprint planning. 

Sometimes crazy things happen such as maybe people get started on the next sprint or they maybe have some ideas for planning they want to think about before they come into the sprint planning. Maybe they want to grab the product owner and say, “Hey I really wanted to get a better understanding of these things that are coming in the future,” and now they've got some time to do those things.

One thing that we talked about always is people have little pet projects they want to take a look at; something they want to research, this new technology... Sometimes the PIO just never prioritizes those things, so this is an opportunity maybe I can get a few hours and look into something and maybe I can come in and make a better recommendation the next day.  

So if you do this, what will the results be? Well first of all, your developers are going to be happier. You're going to have a more sustainable velocity.  Developers will come in and the team will come in more ready for the sprint planning and will have new ideas to bring to that sprint planning. And I think you'll find that what you're thinking, “Wow! There's these four hours of downtime.” You'll find that there's really not downtime and that all or most of this time will actually be spent adding value to your product. So actually, there really is no downtime. So, consider the half-day. 

The Challenges of Agile Software Development eBook

Recent posts

How Continuous Integration Benefits Your Software Development Team
5 Ways To Remove Technical Debt From Your Software’s Code
How Technical Should Product Owners Be In Agile Software Development?
How To Use Sprint Zero To Prepare An Agile Software Development Project

 

Share this article

 

About the author

Michael is the Director of Agile Strategies with Small Footprint, where he leads Agile software development projects and Agile transformations. The goal of his projects is for businesses to deliver high value to customers and stakeholders through adopting Agile across the entire organization, not just the development teams. He has 15+ years of new product development experience, ranging from software engineering to product line management. Michael is a certified Product Manager, Product Owner, and Scrum Master.
Ready to partner with an expert in custom software development? Learn about our fast, cost-effective approach to creating world-class software solutions.
301 N Main St, Winston Tower, Suite 2206
Winston-Salem
NC
27101
USA
Republicii 24
400015 Cluj
Romania

The Small Footprint Blog

Keeping up with the latest in custom software development? Visit Small Footprint's blog for expertise, insights and innovative software strategies.