In the previous articles, we shared some lessons we can all learn from space mission planning. We talked about the approach to project risk and how (and why) to use checklists. We stressed that transparency of knowledge is a strong success factor in terms of product development. It can be achieved by choosing the most appropriate tools and setting a clear course of action by formulating a clear product goal. Now comes the last part, where we’ll tackle the issue of effective planning and suggest what activities you should focus on when observing any dependencies between the elements of the Product Backlog.
Any team can grow its planning skills thanks to its focus and experience. To investigate the level of maturity in that regard, a team should be able to answer some important questions, like:
How quickly are we able to see facts and dependencies?
How precisely are we able to choose the ones that matter most to us?
These are just some of the questions that we should be able to answer, whether we’re creating a space rocket and sending astronauts to Mars or creating relatively less complex products. Noticing changes in the business environment, anticipating important events, and drawing conclusions for our planning are skills our team can focus on. We have a few suggestions on how to do it.
7. Let the team learn to plan
Let’s imagine we have a newly assembled team on our hands. The first couple of sprints may be more prone to overestimation: the team is just getting to know each other, learning its competencies, perhaps even velocity hasn’t been documented. A newly formed team that wants to achieve success should also bear in mind what kind of dynamics come into play. As it is shown in the Tuckman Model (https://hr.mit.edu/learning-topics/teams/articles/stages-development), a team is not a fixed entity, but evolves or devolves under specific circumstances.
Over time the team members learn about the work environment and each other. Change is a natural and sometimes a chaotic process. Depending on the effectiveness of continuous improvement, change can be faster and more focused. As experience grows, so should the precision of our estimations. With every sprint, we should be more aware of different aspects of our collaborative work.
We know that we need to spend a specific amount of time on maintenance tasks in each sprint. For the next planning, let’s take this time out of our capacity and not allocate it to production, but to the tasks we know must be done regardless. If during the sprint, it turns out that such default activities are not needed, or we’re able to complete them faster, we have spare time and can use it to complete the following tasks from the backlog. Before launching the rocket, check all the clocks and indicators. Similarly, when planning a sprint, you should check the metrics regarding how to plan the sprint well.
8. Find your own way
The antithesis for using a learning opportunity may be a situation where an ambitious Scrum Master comes to a new team with a Definition of Done and a Definition of Ready, explaining that the team should implement them as they are. Yes, the Scrum Master’s suggestions may be viable and valuable, but they have a severe drawback. They are not part of the team he is currently working with.
Ready-made solutions may take away the opportunity to learn and grow – to draw conclusions from your actions and decisions. Checklists and standards born from a team’s history of successes and failures are owned by the team – it understands the sense of their checklists much better than they would understand the significance of even the most successful solution used by anyone else. Self-created standards remind a team about its own history and make a significant contribution to its progress.
9. Focus on the Sprint Goal
Another way to avoid overestimation is to prioritize your sprint goal. We already discussed The Sprint Goal itself in a previous article, but how can we use that goal to better estimate work? To start with, you shouldn’t plan without saving some room for unforeseen obstacles. Let’s assume that our capacity is 50. If your sprint goal seems just big enough for the team’s production capacity, the team will end up with no buffer for any unplanned situations. What can be done differently?
The Sprint Goal should be clarified, and on its basis, the tasks necessary to be performed in each sprint should be specified. You may find that the most important tasks weigh only 15 points. That is perfectly acceptable as long as the increment developed realizes the Sprint Goal in its entirety and generates business value. When the entire Sprint Goal is achieved before the end of the sprint, the team can work on the following tasks from the Product Backlog.
10. Visualize dependencies
The fact that the Scrum team does not work in a vacuum is not open to discussion. It often happens that completing a specific task allows another team to continue working with the item. We can imagine many such relationships between SpaceX teams, which must constantly adapt their work rhythm to the work of other teams building the same product together. Although in an ideal world, such situations would not occur, there are dependencies between tasks within one team.
Therefore, it is important to find a way to visualize dependencies transparently between teams and within one Scrum team. This will allow you to precisely define which tasks should be focused on, which exceeding deadlines are particularly undesirable and why. It will also help you discover what factors can threaten your sprint.
The visualization of dependencies increases the sense of responsibility of individual teams. Consider how to clearly and transparently show all dependencies present in the backlog.
We wanted to show you how you can improve your planning process using iterative project planning in these articles. We hope all our suggestions will be helpful and your team will benefit from implementing these ten lessons.