The Importance of Sprint +/- 1

Like everything in the world of programming, the way that we develop software changes along with how we develop it. The concepts of agile development have been around for a relatively long time, with some of the disciplines continuing to be refined. Part of making sure that Agile works as designed is to make sure that you have the proper ceremonies or disciplines set up so that you’re successful in the sprint. One of those things is making sure that you’re doing the right things before and after the sprint.

Sprint -1

You’re always in a sprint, and there will always be a next sprint coming if you’re committed to doing agile. Part of the current sprint should be helping to plan for what comes in the next sprint so that you’re ready when you get there. That means that you should make sure to reserve time in the current sprint for planning the next one.

You should be a part of regular meetings with your team where you’re considering what items come in the next sprint. A review of the stories that are coming next should be performed with the goal of making sure that a story is truly thought out and all questions resolved to the furthest possible.

For example, if you are going to build a new widget on your website, you should have identified in your story the target persona. This is actually one of my favorite things in software development because of a book I read The Inmates Are Running the Asylum (aff). Developing personas can be a lot of fun and you should be able to keep a set of them by name so that you can refer to them regularly and know why they want to do certain things.

Other things you want to cover are the What and the Why you are doing something, figure out your acceptance criteria and review any designs. Think of this step just like an architect building a house that is drawing up blueprints. You’re trying to get a design out of your head and onto paper such that when you hand it over to the builders you have a good shot at getting what’s in your head. And when you’re done with one story, move on to the next one.

Sprint +1

Every sprint should have something that is deployable. That doesn’t mean that every story you work on in a sprint is code that will make it into production– we’ve already seen that some of the work in the sprint is planning for the next one! But every sprint should have a branch where completed work from the sprint ends up such that the development team has done their work and it can be deployed to a User Acceptance environment of some kind.

The way it should work is this:

1. At the end of a sprint, the development and Quality Assurance teams have reviewed stories that they believe to be complete on the development test network.
2. They then deploy this to the User Acceptance environment and move on (or continue on) with the next set of stories toward the next release.
3. While the development team has moved on, the product team, which is customer-focused, socializes the items that have been put on the User Acceptance environment and confirms that what has been delivered is correct.
4. If the product team gives the go-ahead, the solution is deployed to production.
5. Repeat the cycle.

This way, the decision to push to production is made by the product team in consultation with the customer who has approved what is delivered. The cycle of delivery is shortened, which means that stories have been coherently decomposed to make sure that there’s something deliverable. Customers can see items resolved faster than long lead times where they’re waiting a month or more.

Quality and Buffer are the Keys

This plan only works if you build a buffer into your schedule. If you are consistently overbooking your team expecting herculean efforts to get things done, then you won’t have time to do things the right way. If you don’t have a buffer, you won’t be able to handle issues as they come up or be able to be flexible enough to change simple items. You won’t have time to plan.

This plan only works if you have quality built into your code from the beginning. You need to know what you’re building, you know how you’re building it, and at each step of the way you are ensuring that you’re building things that will work in all test cases. Having done your Sprint – 1 work, your quality team should be able to help you with a test plan for your story– that you, as a developer, should be testing. There should be no excuse to get to the end of a story and have QA find many bugs because we all should know what we should build in the first place.

So, wherever you are in your Agile journey, practice Sprint +/- 1 and see if that gives you better results in your future sprints!