Working in sprints: Make timely adjustments so that our customers always know where they stand

Working in sprints originated from the Scrum method. It enables cyclical work in short periods and promotes agile software development. The duration of all the sprints in a project is determined in advance. This is usually between 2 and 4 weeks. We make a new sprint planning for each sprint, carry out the work during that period and end with a review.

At the start of each sprint we make a so-called sprint planning. Here we lay down in detail what we will do in the upcoming sprint. Based on priority and goals, we create tickets in Jira, we make estimates of how much work these tickets will take up and, in consultation with the customer, we fill in an average of 80 to 120 hours of work for the upcoming sprint. We then deploy this work on a test environment so that our customers always have access to their own code.

At the end of each sprint, a new sprint follows. This regularly provides evaluation moments about the previous work. What went well in the last sprint? Do things need to be picked up in this sprint that have been left behind in the past period? All these matters can then be included in the new sprint planning.

Because we look at where we are every sprint, we are not so easily faced with surprises. Determining in advance how many hours we will need for a project is always an estimate and it can always happen that something is more or less work. Because we make a new schedule every time, we often see it coming from afar if that estimate deviates and which choices are responsible for this. This allows us to make adjustments in good time where necessary. Took a little less time than expected? Then we have extra space to deal with peripheral matters. Does a project appear to require more effort than originally expected? Then we can see (in consultation with the customer) where we will prioritize. For example, are there less important parts that we can skip, so that we can stay within budget?