Agile fundamentals for teams

In this video, we’ll begin looking at how Agile teams work. An important part of this is ensuring there’s alignment. This can be with leadership and also amongst the team. 

To achieve this, we’re going to focus on 3 things: a product vision, roadmap and backlog. 

We’re going to start with a vision. This is a statement about the value that your product provides to its users. This is the why. What problem is the product aiming to solve? 

Alongside a vision statement, it's often beneficial to include a set of values, or design principles. Here is an example of Sport Wales’ design principles. They went through an iterative process to develop these. They now act as guidelines for teams. This ensures there is a consistent approach to the development of products. 

Having a vision is crucial because it lays the foundation. It states what you're here for and what you're not here for, better enabling you to deliver on your goals. This is amongst the top recommendations for teams to be effective. That's not only in Agile environments but in all settings. 

The best vision statements describe the motivation behind the product. They are inspirational and are generally short and sweet. A good vision statement is memorable and easy to recall. Once you have this in place, it can help you in your decision making. 

Once you have a vision in place, you can start to develop a roadmap. These are the steps you'll take to achieve your vision. 

The roadmap is a high-level direction of travel. A good Roadmap features goals organised into phases. Examples could include now, next, and later or short, medium, and long term. A roadmap is less detailed as it extends further into the future.  

Goals should be small enough to be measurable. But they should also be large enough to encompass more than one task. A good goal is in the sweet spot, not being too granular but also not being too big-picture focused. This prevents goals from being too detailed. These are crucial in building consensus with you as a team, your leaders and stakeholders. 

Here’s an example. We have an objective and 3 key results aligned to it. It describes what we’re aiming to achieve, without being too specific. This is to avoid constraining the team or stating exactly what they will deliver. It ensures we're focusing on outcomes rather than outputs. It gives teams the creative freedom. They can experiment and find ways to deliver on the objective. 

The key results are things we can measure. They enable both you and your leaders to see whether the things you’re working on are leading them on the right path. 

A great way to structure a product roadmap is using the GO Product Roadmap template. This differs from traditional feature-based roadmaps. Instead, it’s goal orientated. This shifts the focus to outcomes over outputs. It encourages you to consider how you'll add value for users rather than the features you’ll create. 

The most important aspect is the goal. This is where we outline the benefits we’re looking to create.  

A great example of this is from a mobile gaming company. They had a lot of difficult attracting and then retaining users in a competitive market. They switched from delivering a list of features to a goal orientated approach. They focused on increasing user engagement and reducing costs. This shifted their focus away from delivering the next thing, which may not work. Instead, they began identifying, testing and delivering improvements aligned with their goal. 

You can add timeframes or dates. This is often something that’s asked for by leaders or stakeholders, so it can be useful for alignment. But, if you don’t have the need for this, you can remove it. 

Next, we can add a name or a version for any major releases. You could use version numbering for this, or you can get creative.  

As an example, Apple uses version numbers for macOS. Their major releases are macOS 12, 13, 14 and so on. But they also name these based on places in California, like Monterey, Ventura and Sonoma. 

There’s no right or wrong way to name your releases. The purpose is to differentiate between versions. So choose whatever approach works best for you. 

Next consider the capabilities that you need in the product. What does it need to do to help you meet your goal? This means you identify the goal first, then the features that align to that second. Usually, teams will choose between 3 and 5 features per goal, per release. 

These should still be high level and not too detailed: save the specifics for the backlog. 

Finally, we get to the metrics, or key results that I mentioned earlier. These are the measures we use to determine our progress towards the goals. Having these makes our goals specific and measurable. 

Over time, as your product develops, your roadmap will evolve. You'll move on to new goals and objectives to tackle.  

So, here’s a model to help guide how often you may need to review it. 

It’s based around two factors. On the Y axis, we have Maturity. This is considering where the product is in its lifecycle. Is it something that’s brand new or is it a product that’s well established. Along the X axis we have stability. This considers the context in which people use the product and how stable it is. Is there likely to be much change? 

The 4 quadrants give a guideline about how often you may need to review your roadmap. As a general rule, a new product used in a changeable environment will need regular reviews. But as the product becomes more mature and the context in which it's used is more stable, reviews will be less often. 

Finally, we get to the Backlog. These are the things you’ll be working on, aligned with the goals in the roadmap. 

The backlog is a prioritised list of the deliverables you are working on. 

It may include Epics. These are the large chunks of work that you are delivering. For example, it could be launching a new part of the product or a piece of functionality. 

The backlog should also contain user stories. This encourages you to think in a user centric way by considering the who, what and why. We will cover these in more detail, including what they are and how to use them, later in the course. 

Finally, we have tasks. These are the things you’re developing are meeting the user needs that we’ve identified.  

A backlog is dynamic and will change as you develop the product and gain new insights and feedback. 

Later in the course, we’ll focus on building a backlog, featuring tools to help with planning and managing it.