From the point a user story was estimated to its completion, the given estimation might not apply anymore, and that’s completely acceptable. In the end, by assigning story points, or T-shirt sizes, or any other system you may use, the team is forecasting based on the information they have at that point.
The Development Team’s work should be divided into several areas. Apart from user stories, there should also be time allocated for the team to improve their skills, be creative, and try to refine some of the areas, or research technical approaches that could become useful in the future.
It’s not unusual to have some sprints where the work that was previously planned at the beginning of a sprint, be done earlier than expected. Only make sure that the team spends the rest of the time productively. Still, if that happens too often, that should be something you might want to look into.
Let the team learn something new
Various projects offer various growth opportunities for the Development Team. There are many industry sectors where projects can be developed, such as Life Science, Finance & Banking, Healthcare, Education, and many others. It’s good and sometimes even mandatory for a team working on such a project to have training that will help them learn about constraints or best practices.
For example, within the Healthcare industry, where patient’s confidential information is at stake, the team working on that project must know very well the constraints and the security measures they need to take. Typically, this is information that should be known from an early stage, but it can always be revisited to make sure the terms are taken into account. So this is a good way for your team to spend their time in a sprint.
With different projects, come different technologies, tools, and frameworks. In companies that are developing their product (SAAS), it’s more difficult to have different technologies, use different tools and frameworks. But team members can still learn more about the technology and even prepare to take a certification exam.
In many companies, there are so many different clients for which teams are building products. And as many new technologies, tools, and frameworks to learn about. So gaining more knowledge about these, it’s a good way to spend the remaining time.
Refine the backlog
Together with the Product Owner, the Development Team can invest the time into refining the backlog. A well-groomed backlog is necessary to forecast the upcoming sprints. Say the team reached the sprint goal with one day before the end of the sprint. The entire team can then get into a three or four hours workshop. In this workshop they can analyze the next most important items.
It’s a good opportunity to split the Product Backlog items into small stories and estimate them. Do not end the sprint earlier only because the items were finished, this is a good subject to discuss in your Retrospective.
If you have this refining session before the day you have planned it to happen, it’s totally fine. You can skip the next refinement and focus on the actual implementation.
Drag another item from the Product Backlog
This is the easiest approach if your Product Backlog is will be organized. Normally, the most important next items that should enter the sprint will stay at the top. A good practice is to have the work for at least one sprint estimated in advance.
If the team or even one member is finishing the work earlier, the Product Owner can drag another item into the Sprint Backlog. This should be always discussed with the Product Owner and the team shouldn’t take random tasks from the Product Backlog. The Product Owner may need to inform the stakeholders about the change and he cannot do it if he is not aware of why and how it occurred.
What if the new User Story will not be finished in that sprint? Does it mean that the sprint failed? Not really, as long as your initial sprint goal was achieved, you can consider the sprint successful. Your burndown chart might not look as good as you’d like too but what is more important than that burnout chart, is what you will deliver.
Stakeholders and clients won’t look at how many user stories got moved to the next sprint, as long as the initial goal was achieved. If you can do something extra in advance, that’s great. However, it’s still a topic to discuss in the Retrospective if it repeating too often.
Approach the subject in the Sprint Retrospective
There will always be sprints with mismatchings between what was forecasted and what was done. The team can be mature and composed of experienced members that almost always estimate accurately. But even so, it can still happen.
But when it happens too often, there are some reasons behind it and you should understand what are those reasons.
For example, the team might avoid taking too much work in the sprint and they overestimate tasks. It’s often happening when the velocity of the team keeps growing. Because as it grows, the team gets more and more work. They might feel at some point that it’s too much and they begin adding up to their estimation. They do that to be sure that they will finish in time what they forecasted.
Also, if as a team, you are aiming for the perfect Burndown or Burnup chart, the developers will be very cautious with the amount of work they accept into a sprint. So you must be careful about what kind of expectations are created with those metrics. Most importantly, be sure that you use them for the right purposes.
In most cases, the requirements are not well understood. All team members should have the same understanding of what’s needed for specific functionality. If that doesn’t happen, it’s much more difficult to get to a consensus. Before estimating, make sure that everyone understood very well the requirements.
Be creative
From time to time, the team can propose a new functionality. It can be an enhancement of what they have previously developed or a new feature. And even if Product Owners often don’t want to hear about code refactoring, sometimes can be the best decision to make.
Any new functionality, should, however, be related to the product that is to be delivered.
This is a factor that in general is motivating the Development Team. When they feel responsible and accountable for something they have proposed, they will be more committed to the work they do.
There is always work to do and always something that can be improved in software development. You just need to find what best works for the product and the team. If what the team is about to work on to fill in the remaining time in the sprint is not bringing any value to the product, then you should find something else that will.
Even when team members are investing the time in learning more about a tool, a framework, or improve their coding skills, it should all be done with the business’s needs in mind.
