In the previous part of the article, our experts shared three lessons on iterative project planning. They shared, among others, considerations about the “sprint zero”, and advised on how to approach project risk and how (and why) to use checklists. In the second part, we prepared three more lessons on product goal creation, self-organization tools, and the dangers of overestimation.

Planning subsequent increments in the context of agile methodologies, such as Scrum, is usually accompanied by gathering knowledge about the product. The effectiveness of our activities depends on how precisely we define our goals, to what extent we achieve transparency of the acquired knowledge, and whether we plan the next sprints well enough for the following increments to reach the highest possible business value.

4. The product shouldn’t only have a vision but also a goal

Let’s assume that as Scrum Masters, on the eve of our first sprint planning, we already have a complete team of developers capable of producing an increment and a Product Owner. To start the sprint, we need something else. We need a Product Goal.

The goal is something other than a vision and was not introduced to the Scrum Guide until 2020. While the concept shows us what the finished product would be like after all the most important iterations, a goal has a much shorter time horizon. A goal answers questions such as: “what client needs should our product respond to after the first few sprints?”.

SpaceX’s single vision is to put a man on Mars, but Elon Musk’s company creates a whole range of products essential for the mission to succeed. Some of the products are Dragon modules, Falcon rockets, and Raptor engines. To conquer Mars, we would also need a trained crew. All these elements support the overarching vision.

Now let’s take a closer look at one of them: reusable rockets. A space rocket that returns to the ground is an essential product that significantly increases the efficiency of each flight. It fulfills a specific short-term goal that is a part of a broader vision but is not sufficient in itself to achieve it. However, if SpaceX had not focused on individual, minor products, it couldn’t have created and tested a reusable rocket.

Having a clear product goal is important because it allows us to better organize the Product Backlog before and during planning. To formulate the Product Goal, we need to answer several other questions:

  • Why are we making the product?
  • Who are we making it for?
  • What need is it supposed to respond to?

We can use one of the many available and widely used tools, such as Design a Box, which aims to illustrate only the essential functions our product should have.

5. Choose the most appropriate tool

As Scrum Masters, we know that if the product has many dependencies, then visualization is necessary to better understand the problems we will face in each sprint. Especially now, in the pandemic era, instead of Post-it notes, people are working with remote tools. Some of them are relatively simple and easy to use. Others are more like complex mechanisms in their rights. Using them during planning sessions may be a struggle, and creative cooperation may run into unnecessary barriers. How to avoid them?

The first step is to ensure that every relevant piece of knowledge about the future product is readily available. Ideally, everything meaningful to the process should be in one place. Unfortunately, teams often use multiple tools at once, which means they must jump between Google Docs, Miro boards, and Jira in their search for information. Each of these tools helps you achieve a slightly different set of goals. Each tool is effective in its way.

But on the other hand, it’s important that the Product Backlog is transparent and always available to the team, aggregating information about the work. It’s an incredible waste to save knowledge or information in many not always easily accessible places on various platforms. Scattered knowledge can be seen as the antithesis of transparency and reduce the team’s focus on carrying out tasks.

The next step is to make the knowledge complete, considering only the most important measures. This allows the team to plan according to facts, not opinions.

Many of us worked in teams that didn’t use any metrics, which often turned planning into reading tea leaves. If the team has unambiguous indicators telling (let’s say) which task should be completed at a given moment and what dependencies are involved in getting the job done, it will help them avoid any unnecessary disputes and conflicts.

Another indication of a good tool is whether it’s used by the entire team. This not only reduces the complexity of work but also means that the team does not need a “scribe” whose only role is to write down agreements, modify, boards or move virtual post-its.

A good tool not only supports the team’s work but integrates it by increasing the level of cooperation and even helps to implement the values of Scrum. It gives each team a chance to work even without a Scrum Master present. A good tool does not come from outside of the team (e.g., from the manager). It is the Scrum Team that should choose the tool that best suits their real needs.

6. Avoid overestimation

In many teams, estimation takes place on two levels. At the “higher” level of User Stories, the standard is to use Story Points, and for the “lower” level of tasks, man-days are often used to measure workload. The team needs to determine the extent to which developers in each sprint will be available before planning. The scope of the sprint should be planned accordingly.

There are cases when the team tends to overstate its capacity, ignoring the importance or size of an individual task and putting too much faith in its abilities. This is an easy way to overestimate the scope of a sprint. What is the usual outcome? The team is not delivering some of the important items or even failing to meet the Sprint Goal altogether.

To help such a team, a Scrum Master should unpack some of the pre-assumptions this team may have. They can be expressed in various ways, but the most common form is: “we are here to write code – our value as a team is measured by the lines of code we can write.” If the team makes its value dependent on the amount of work, it’s no wonder it wants to do more. Often with little regard to quality or business value.

The solution would be to replace this destructive pre-assumption with a different one. For example, “our strength as a team is measured by our predictability to deliver real business value.” If we take on tasks, we should ensure that we have them completed according to the Definition of Done by the end of the sprint. When the precision of our estimates increases, organizations, contractors, and customers will trust us and hold us in high regard.

Hungry for more lessons?
Check out the last part of our article!


back to blog