Agility, or the ability to respond to change in your market, is often considered one of the most significant predictors of a company’s success. In fact, Agile projects enjoy a 60% greater chance of success compared to more traditional “waterfall” type projects. 

But what is Agile? The concept of an Agile approach is something that gets thrown around a lot. But there can be a lot of confusion about what it actually entails. Is it something to do with walls full of colourful sticky notes? Is it fancy project management software? Or something you can only learn from specialised consultants?

In this post, we’ll go over the key and most important concepts and processes of Agile product development, and how you can apply it to your own organisation.

First, before we look at Agile let’s take a look at waterfall:

Waterfall

‘Waterfall’ is the name of the more traditional style of product development, for both software and physical products.

It follows a linear process. To start, there is typically a lengthy planning process, where absolutely everything for the entire project is planned. This planning stage can take several months.

After planning is completed the project will move on to the next stage, ‘Design’ where the entire design of the product is finalised. The project continues moving through the stages, always completing the last stage fully before moving on to the next.

Finally the full finished product is released to market, months if not years after the initial planning stage. As a result, the wrong product could be brought to market. What originally could have been a well planned product with a great market fit could now be outdated by the time it’s released. Technology may have changed or market demand may have shifted.

Waterfall vs. Agile

So we’ve looked at waterfall, but what does it have to do with Agile?
Well, with Agile we break the waterfall process down into smaller pieces.
First we do just enough planning to get started. Rather than planning the entire product, we will just plan a very small component of it, perhaps just a feature or two.

Then, we aim to do just enough building and designing so we can ship this small feature set - also known as an ‘incremental release’.
In Agile, this entire process, from planning to the incremental release usually takes about 2 weeks and is often referred to as a ‘sprint’.
Once we have made a release, we start the cycle again. Each time, we’re only doing enough planning to build the next incremental release of functional software.

By shipping small regular releases, the product process is flexible. As we ship in small feature sets, or incremental releases, we can quickly start to test and gather user feedback on each shipped feature. This continuous testing means we can respond quickly to new and changing requirements. As a result, we can continuously adjust the near-term roadmap to meet customer needs, meaning we are far more likely to deliver a final product that our users love.

Agile Principles

1. 1-Reflect and adjust: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
2. 2-Satisfy the customer: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
3. 3-Deliver frequently: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. 4-Self-organising teams: The best architectures, requirements, and designs emerge from self-organizing teams.

As you can see from the principles, Agile isn't a list of processes to follow when creating a product, but rather its a set of values and guiding beliefs that can be used to help make decisions when developing products.

If you’ve been learning about the ‘Agile world’ then there's a good chance you’ve also heard other terms, like ‘Scrum’ and ‘Kanban’. Scrum and Kanban are popular Agile methodologies. They are product development frameworks that are designed to help teams achieve the Agile principles.

However, while these methodologies can help a team into being Agile, they aren't necessarily Agile in themselves. Following these methodologies only results in an Agile practice if it helps the team achieve Agile principles. You don't necessarily need to follow a methodology or processes strictly if you find it's not helping your team achieve the Agile principles. Is the team reflecting and adjusting? Are you delivering features frequently? Achieving the Agile principles is what determines if a team is truly Agile.

Maybe you’re following Scrum, which suggests having a daily stand up meeting to connect with your team. But after following it for some time, it just isn't working out. You find your team is more productive and content having sit down meetings around a table. That's fine too! You can make that change. Part of Agile is responding to change, reviewing your processes and adapting, and that can mean adapting how you structure your product development too.

Ultimately, you should use whatever you find helps your team best make Agile decisions. There's not one true method or system that is the only way to be Agile.
For teams new to Agile, it may be easier to follow an established methodology to get started with some structure in place, then once your team feels comfortable you can try changing the formula.

Who makes up an agile team?

An Agile team is made up of a:

Development team
This team often includes skills such as design, development, testing, and delivery. Team members often play multiple roles, some days they could be testing and other days developing.

Product owner
A product owner is responsible for maximizing the value of the product created by the development team. This internal-facing role gathers technical requirements, grooms the product backlog, and details user stories.

Stakeholders
Stakeholders can be anyone affected by the development of a software project. This includes a broad category of people, such as end users, executives and IT.

Understanding your users

Before we go further, let's go over communication with users and understanding their needs.

At the very start of a product development, and consistently throughout you should be communicating and testing with users. This is usually a job mainly for the UX professional on the team, if you have one, but really all members of the team should be encouraged to regularly talk to real users.

User communication can be done in a number of ways:

• Interviewing current users about how the product works in their life.
• Allowing users to test your new features after a sprint and give feedback.
• Asking potential users about their experience with competitors products.

The aim of the user communication is to identify user needs. An example of a user need could be to ‘conveniently compare mobile phone tariffs’. User needs should always be based on real conversations with people, not needs that the team thinks the user wants.

Setting the product strategy

At the beginning of a new Agile product development project, you need to define the product strategy. This summarises the business need that your project is addressing. In more simple terms: what is the end goal of this Agile project and how will you achieve it?

Product owners are responsible for creating a product strategy in collaboration with their stakeholders to secure buy-in and alignment. It is optional, but recommended to include key members of the development team too.
Setting a clear strategy is crucial in an Agile environment. Development teams can sometimes feel caught up in the details of a project and lose sight of the overarching purpose behind all of their work. The product strategy is a high level goal that the team can refer to to make sure they are seeing the big picture.

To prepare for a product strategy meeting, you should have already worked closely with users to understand their pain points, researched the market, and be aware of your overall business objectives. There are many templates and canvas tools you can use to help you create your product strategy. One that I think is very beginner friendly is the Elevator Pitch method.

Creating the prod roadmap

After the strategy is decided, the product owner with stakeholders will hold a meeting to start planning the product roadmap.

The product roadmap is a high-level view of the requirements, priorities, and a loose timeframe of how it will all get completed.

Jeff Gothelf, author of Lean UX, explains the dilemma of Agile roadmapping well,

“One of the biggest challenges in product management is planning the work in a linear, visual way…Digital product development is not linear. It is iterative. We build some things. We ship them. We see how they impact customer behavior. We iterate them and ship again.”

Agile projects are flexible by nature, so planning the roadmap for the next year or two can be a challenge and should be approached differently to normal roadmap planning.

Just like with setting your product strategy, you should first be talking to users and identifying their needs before the roadmap meeting. User needs are fuel for planning!

1. Start thinking in themes:

You should have discovered some problems or areas for improvement while talking to users, and with those and your business needs in mind you can start creating your themes.

Themes are items on your roadmap. They should speak in outcomes, not features. Outcomes are measurable specific changes in either your organization’s or your users’ lives that you wish to achieve with your product. Features are merely the ways we reach that outcome.

For example, an outcome we might want to achieve is ‘Less website visitors abandon their shopping cart’. And a feature we could build to help us achieve that could be automatically offering promotional codes when something is added to a shopping cart.

However, at the roadmap level we don't want to list our ideas for features, those will come later. By using outcome based themes, we keep our roadmap at a high level, meaning we can be flexible and switch features in and out of the theme without significantly affecting the roadmap.

2. Measure product success:

As the saying goes, “You can’t improve what you don’t measure.”
For each theme you should decide as a team what metric or KPI you will use to measure success. This will help us assess the quality of a product and track team performance.

Common product success metrics are measured by how users interact with products and services, such as customer engagement, conversion rates and customer churn.Take care, though. You don’t want to measure one facet to the detriment of other information. And you don’t want to measure too many things and scatter your team’s focus.

3. Create epics:

Under each theme, the roadmap will include one or more epics (bodies of work to serve the theme). Each epic will consist of the relevant features and stories needed to complete that epic.

There is often discussion in Agile circles about the difference between epics and themes. A theme is typically a grouping of similar epics. But whatever your definition, it’s important to keep the themes at a high level.


4. Prioritize:

Once you have identified several themes your team has deemed important, you need to prioritize them. After all, you’ve got limited resources and can’t tackle everything at once. So, with consideration given to your KPIs, product strategy, and available resources, you can start ranking your themes.


5. Iterate:

Much like the products produced by Agile teams, Agile roadmaps are iterative. Agile planning and roadmapping processes are ongoing activities that should be adjusted regularly to accommodate change.

For example, unexpected opportunities in the market might appear on the horizon that your company would be foolish to pass up. For companies to survive in a volatile marketplace, not only can roadmaps change, they must change.

The product roadmap is not just for business stakeholders, but for your whole product team too. The roadmap gives your team insight into the bigger picture of your product, and how the work they are doing today fits into that picture. As a result they can make better-informed decisions in their work.

It also serves as a good way to keep executives and stakeholders on the same page and focused on the big picture. It’s this use of your product roadmap to better communicate your long-term strategy to your team and stakeholders that highlights one of the most useful benefits of a product roadmap, a communication tool. And for more detailed, tactical plans? Then we use the product backlog.

Product backlog

A good Agile product roadmap provides context for the product backlog. This is where we start getting into detail.

It is the single authoritative source for things that a team works on. A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome. You can think of a backlog as a ‘To do’ list for the development team.

As requests, user feedback, and new ideas come in, you’ll end up with a ton of potential features and projects to take on. These live in your product backlog until you’re ready to add them to a sprint.

Nothing gets done that isn’t on the product backlog but conversely the presence of an item in the product backlog does not guarantee that it will be delivered. Backlog items are simply options that the team has for delivering a specific outcome rather than a commitment

Your backlog is flexible. The backlog manager, usually the product owner, should be able to quickly add or remove items to your backlog. Your backlog should be constantly adapting to how you think your team can best achieve the desired outcome.

Product backlog items take a variety of formats, with user stories being the most common.

User stories

User stories are simple stories that describe something that would give the user value. They help us organize our work into bite sized chunks. A common format used for user stories is the ‘Who, what + why’ format below:

As a <role>
I want <goal>
So that <benefit>

For example, ‘As an self employed person, I want to easily and stress free track the work related finances, So I can be confident i've paid my taxes correctly’

User stories can help us follow one of the key Agile principles: “our highest priority is to satisfy the customer through early and continuous delivery of valuable software features”

At the end of our 2 week sprint we aim to have delivered our incremental release of valuable software features. In order to complete user stories, and deliver valuable software, we only focus on building what is necessary to deliver the value.

For example, in waterfall we may want to build the entire database for the whole product first before moving on to other parts of the structure. In Agile, we will only build just enough of the database to deliver the feature.

It may feel unintuitive at first, and you may have to go back and rework things you did in the past as future user stories become more clear. But it's important to remember that the Agile methodology is a more efficient way to build products. Instead of waiting years to launch a project, within weeks you are able to ship functional features that add value to the user and the business. From the features you ship, you can gather feedback for future iterations, and adapt quickly to market changes.

Sprint backlog & sprint planning

Once the product backlog has collected enough user stories to get started on shipping some features, you are ready for the sprint planning meeting.

A sprint typically lasts 2 weeks and is repeated many times. In each sprint you're just planning and building enough to launch the next incremental release. The sprint cycle is repeated until the product is complete.

Before a new sprint, your team will have a sprint planning meeting to create the sprint backlog. While you don’t want to spend too much time at this stage, it could realistically take you 2–4 hours.

The sprint backlog is like a subset of the product backlog. The team discusses which stories from the product backlog they want to pull into the next sprint.

Sprint planning in Agile is done by the product team but should include input and guidance from the product owner. However, ultimately it’s up to the team to decide what should (and can) get done in a sprint.

While sprint planning, you’ll naturally find some of the user stories in the backlog are lower priority to the user. When deciding what user stories to work on in this sprint, ideally we want to build high priority stories first.
But how many should we pull into a sprint? We have a fixed time, and obviously can't build and release them all.

A popular method to prioritize user stories in sprint planning is to use story points. This is where the team discusses stories votes to allocate stories with points, to estimate how much effort a story will take. This way you can have an idea of which are bigger stories, and which are easy wins. Then the team decides which stories can be completed within the sprint time frame.

As your project continues a predicted velocity will become clear - roughly the amount of points your team can handle in a sprint without being overworked or losing quality. This helps with future planning.

Estimation is hard, and with a new team it can be hard to predict estimated effort, so don't worry if you realise after a few sprints that you need to recalibrate your estimates. As always with Agile, reflection and adaptation are key.

In the sprint planning meeting, you should also revisit your definition of “done”: This is how your software will look like at the end of the sprint. It’s important that the people doing the work (the developers) and those inspecting it (the product owner and other stakeholders) are all on the same page here.

Daily meeting

Daily meetings are commonly known as ‘standups’ under the scrum methodology. Agile projects move quickly. And so it’s necessary that you have regular moments to check in and make sure there aren’t roadblocks getting in the way.

A daily 10–15-minute meeting is an opportunity for your team to come together to discuss three things:

• What did you complete yesterday?
• What are you working on today?
• Are there any roadblocks getting in the way?

While this might seem like an annoyance to some of your team, these meetings are essential for communication that drives Agile project management. Agile depends on reacting quickly to issues and voicing them in a public space is a powerful way to promote cross-team collaboration.

Review

At the end of each sprint, the team will have shipped a functioning piece of software. This is a huge milestone to celebrate! After the sprint, we hold a sprint review meeting where we review what was done and share it with people on our team and any key stakeholders. Think of it as Agile show-and-tell.

The objective of this meeting is to prove that the sprint goals were (or were not) achieved. Check your initial plan and make sure all requirements were met according to your definition of done. You can start to identify changes or bugs that can be added to the product backlog and prioritized for the next sprint if desired.

If something went wrong, ask why? How can you adjust the next sprint so your team can hit their targets? Agile is all about continuous learning and iterations, and this means on your processes as well as your product.


Now, it's time to rinse and repeat! Time to start the next sprint cycle with a sprint planning meeting.