Agile product management

What is agile product management?

How do we define agile product management? It is a product development philosophy that emphasizes a flexible and human - rather than a rigid process- or tool-oriented - approach to defining product strategy and carrying out work. Teammates focus heavily on customer feedback to make improvements and adjust roadmaps throughout the product management process. This creates more responsive teams, leads to quicker iterations, and creates a more lovable experience overall.

 

Benefits of agile product management

Agile redefines how product managers think about planning and building products. Traditionally, new customer experiences were planned, designed, implemented, and tested in a step-by-step way. This meant that new functionality was delivered sequentially. Once requirements were defined and handed off to the development team, it was difficult to make any changes. The failure rate of large-scale and lengthy software development projects drove the need for a more fluid approach. Teams needed a way to adapt to customer feedback and other learnings.

Agile provides a more flexible approach than traditional software planning and development. Products are built in short increments, giving product managers the opportunity to adjust the plan along the way. Here are some of the key benefits of agile product management:

• Learn from customers throughout the product lifecycle
• Continuously adjust the near-term roadmap to meet customer needs
• deliver value to customers in an incremental way
• Respond to new and changing requirements
• Collaborate with engineering to quickly deliver work

 

 

Agile product management practices

Being a product manager in an agile environment requires flexibility. This is because less time is spent defining the product upfront, so product managers must continuously adapt the product roadmap and reprioritize what to build based on customer feedback.

Here is an overview of how the core product management responsibilities are carried out in an agile environment:

Set product strategy

Setting a clear strategy is crucial in an agile environment. Product managers are responsible for defining the product vision and long-term direction. This requires working closely with customers to understand their pain points, researching the market, and setting strategic product goal and initiatives that align with overall business objectives.

Understand customer needs

Agile methodologies focus on delivering value to customers quickly. This means product managers must stay close to customers to understand exactly what they want. One tenet of agile is gathering feedback early and often to ensure the product delivers the expected benefits to users.

Create the product roadmap

An agile roadmap sets a near-term plan for achieving the product strategy. It typically represents monthly or quarterly commitments and is adjusted regularly to accommodate change. Product managers build the roadmap around strategic themes of work that maintain the overall vision and deliver meaningful value to customers.

 

Prioritize features

Agile product management involves continuously prioritizing features for implementation — maintaining the product backlog, defining user stories, and deciding what to build and when. Product managers work closely with engineers to estimate features, define requirements, and collaborate on a release plan based on the team’s capacity.

Release customer experiences

Agile teams strive to frequently deliver new customer experiences. The cadence can vary from quarterly to monthly, weekly, or even daily. Regardless of the frequency, product managers are responsible for delivering a Complete Product Experience (CPE) to customers. This involves working closely with engineering, IT, marketing, sales, and support to ensure organizational readiness.

Measure product success

Product success in an agile environment is measured by how customers interact with products and services and the impact on customer acquisition, growth, and retention. Measures of success include customer engagement (such as time in product and returning users), conversion rates, customer churn, and the frequency of feature updates.

Roles and responsibilities in agile product management

Agile methodologies introduce a number of additional roles to structure how team work together. Since we already described the core responsibilities of a product manager in agile, let’s look at some of the other roles that are explicitly defined in the scrum framework.

Development team An agile development team is a cross-functional and self-organized group of people that have the necessary skills to produce a working, tested increment of a product. The team often includes skills such as design, development, testing, and delivery.

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, refines the product backlog, and details user stories.

Scrum master The scrum master is a servant-leader who is responsible for coaching the team in agile practices. This role guides the team through the agile process to complete the work the product owner prioritizes. Scrum masters remove impediments that keep the team from doing their work.

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

Product manager vs. product owner

It is important to understand that these are roles rather than job titles. This can create confusion about the differences between a product manager and a product owner. In reality, the product manager is the product owner. This is because the responsibilities of a product owner fundamentally cover the internal-facing work a product manager does — working closely with engineering to build new customer experiences.

Some organizations choose to break out product management work into two roles. In this situation, the product manager assumes an external focus, while the product owner details user stories and participates in scrum rituals. Both roles are important to the overall success of a product and must work closely together to build products that customers love.

The table below explains how the responsibilities of a product manager and product owner differ when they are discrete roles:

Responsibility	Product manager	Product owner
Define the product vision and set the long-term direction	X
Conduct market and competitive research	X
Work closely with customers, prospects, and partners to capture their needs	X
Build the near-term product roadmap	X
Prioritize and score features based on customer and business value	X
Communicate the product vision and business intent to the development team		X
Lead technical requirements gathering, consulting with internal stakeholders		X
Refine the product backlog, breaking down epics and estimating user stories.		X
Attend scrum meetings including sprint planning, standups, and retrospectives		X
Document user story details, create mockups, and work with UX on design		X
Document new features for implementation		X
Support non-technical teams (sales, marketing, support)	X
Write acceptance criteria	X	X
Attend iteration demos	X	X
Demonstrate the latest iterations to customers and gather feedback	X	X

Agile product management tools

As you have learned in this guide, agile product management requires a specific way of thinking and working. There are many tools you can use to help you carry out your core product management responsibilities in an agile way. Here are a few of the most common ones.

Goal matrix

Setting measurable, time-bound goals helps product managers prioritize features that deliver strategic value. Use a matrix to visualize your goals so everyone understands the “why” behind your product decisions.

Planning board

A visual planning board is useful for organizing features into backlogs and upcoming releases. 

This makes it easy to define and prioritize features as you prepare for development.

User story maps

User story maps give you a way to visualize work based on what your customer is trying to do. 

This helps you prioritize the user stories that deliver the most value for customers.

Burndown charts

Progress is tracked using a release burndown chart. 

This shows the amount of remaining work that the team needs to complete 

so you can quickly see if the release is on track.

Agile Retrospective

 

Agile retrospectives for continuous improvement

An agile retrospectives is an opportunity for agile development teams to reflect on past work together and identify ways to improve. Agile teams hold retrospective meetings after a time-boxed period of work is complete (typically a sprint lasting two to four weeks). During the agile retrospective, the team discusses what went well, what did not go as planned, and how to make the next work period better.

Even if you are not on a development team, you can probably relate to the concept of retrospection. Have you ever worked hard on something only to realize later that you should have done it differently? It is not always a good feeling, but the solutions you uncover in hindsight can be valuable input for your next try. The same goes for your successes — acknowledging what went well and is worth repeating can be just as impactful.

What is an agile retrospective?

In short, an agile retrospective is a meeting that happens at the end of an agile development iteration. Team members share their highlights, challenges, and learnings from the last cycle. This helps teams apply these lessons later — easing up future work.

Agile retrospectives (also called scrum or sprint retrospectives) are closely tied to scrum methodology. Retrospective meetings originated as one of the official scrum ceremonies. In scrum, agile retrospectives include the entire scrum team (comprised of a scrum master, product owner, and developers) and often product managers as well.

Regardless of your chosen agile methodology, most agile teams approach retrospective meetings in a similar way. The details will vary but the purpose of the agile retrospective is the same — to reflect on past work and potential improvements. This guide will primarily focus on agile retrospectives through the lens of scrum, but any team can apply these practices to retrospective meetings.

 

Why are agile retrospectives important?

The twelfth principle of the Agile manifesto states: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly."

Agile retrospectives put this philosophy into practice — helping to ensure that issues that impede performance or productivity do not go unnoticed or unaddressed. Holding these retrospective discussions at a regular cadence means that problems can be resolved before the next period of work even begins.

Agile retrospectives are also an opportunity for every voice to be heard. There is no hierarchy in a retrospective meeting — everyone can contribute ideas, vent frustrations, and help make decisions. This fosters deeper connection and engagement.

Ultimately, agile retrospectives underline what agile software development is all about: promoting adaptive planning, incorporating feedback, and working in increments. These concepts apply primarily to the development work itself, but agile retrospectives also enable teams to apply these practices inwardly.

 

What do teams discuss in agile retrospective meetings?

Discussion items for retrospective meetings can either be technical or team-related. What matters is that you discuss what is and is not working well. To do this, you might ask the team which moments felt particularly productive and collaborative — or where there were workflow gaps or misaligned expectations.

The most important thing is to leave the retrospective meeting with actionable ways to work better together. These action items should be simple, effective, and easily doable within the next sprint.

The table below provides a few examples of discussion topics and action items for an agile retrospective:

Discussion Topic or Issue	Action Item
User stories were very clear and well-written.	Keep using the new user story template.
Team workshop on extensions was really beneficial.	Schedule another workshop or learning opportunity for the team.
Several teammates struggled with the workload last sprint.	Revisit capacity estimates as a team.
Scrum board layout is cluttered. It is difficult to see priorities.	Set aside time to clean up and reorganize the scrum board in your development tool.

 

Types of agile retrospective workflows and techniques

Over time, retrospectives can become stale and teams might find it more difficult to find areas to improve. Seasoned agile teams may need a push to keep the momentum going.

There are several techniques to help you refresh your agile retrospectives. Here are some of the most common conversation starters:

4 L's	The 4 L's are Liked, Learned, Lacked, and Longed For. This is a simple structure for examining positives and negatives — both technical and team-related.
Dot voting	When there are too many discussion items to cover in one retrospective, hold a team vote. With dot voting, everyone votes on their top three discussion items — the results determine priority. The name of this technique comes from in-person meetings and putting dots on paper sticky notes.
Lean coffee	Lean coffee takes dot voting further. Instead of the facilitator preparing the agenda ahead of time, the team determines the agenda together using a simple kanban board. You brainstorm what to discuss, prioritize items (typically by dot voting), and agree on the flow of discussion.
One word	Participants share a single word to describe their feelings or impression of the sprint. This is a low-pressure way to get everyone participating from the start of the meeting.
Past two months map	The team creates a timeline of the last two months with important events and call-outs. This sets the stage and helps refresh everyone's memory at the beginning of the retrospective discussion.
Sailboat	Sailboat is a visualization tool that portrays the sprint as a boat — rocks represent risks, anchors are delays, wind is what propels you, and land is your ultimate goal.
Start, Stop, Continue	Simply put, this exercise frames the conversation around what to start, stop, and continue doing based on goals and resources.
Question cards	The team uses a set of questions cantered around the principles of the Agile Manifesto. You draw a question card to kickstart the conversation. Examples include: "What is most important to you right now?" and "What are you putting up with that needs to stop?"

There are more agile retrospective activities to try beyond this list. Research different techniques, create your own, and switch up your approach from time to time to help the team stay engaged.

Agile retrospective best practices

Ideally, agile retrospectives involve open and productive discussion — but this is not always easy. Try these best practices to ensure that you create a positive atmosphere for your meeting:

1.  Set an expected duration and frequency Retrospectives usually happen at the end of each sprint. Take 30 to 45 minutes per week of sprint time with a maximum of three hours. If you hold a long retrospective, make sure to take breaks.

2.  Come prepared Choose a framework for the discussion and set your agenda. Retrospective discussions can be fun and low-key — but a solid structure will help you accomplish everything you need to within the allotted time.

3.  Choose a facilitator Designate a point person to keep things moving. On scrum teams, the facilitator will typically be the scrum master. But it is worth rotating the role of facilitator to introduce new perspectives.

4.  Keep it collaborative Everyone should feel comfortable contributing (whether by speaking, writing, or voting). If team members are hesitant to open up, try easing the tension with small talk, games, or fun themes.

5.  Encourage honesty Transparency is not always easy in a team setting. Welcome a diverse range of opinions by remaining objective, asking clarifying questions, and directing criticism towards work and not individuals.

6.  Promote shared responsibility Agile is a collective effort. When things go wrong — or right — the whole team is responsible. No one should feel singled out and recognition should be shared by all.

7.  Do not end the meeting without action items By the end of the agile retrospective, the team should agree on at least one new idea to implement in the next sprint.

8.  Make meeting notes accessible Document, save, and share insights with the team to help everyone stay informed and accountable. 

What is an agile retrospective agenda?

Below is a sample agenda for an agile retrospective to help you make the most of your time. Meeting lengths will vary from team to team, but each segment of the meeting should take roughly the same amount of time.

• Set the stage: Welcome everyone to the meeting, go over the agenda, and introduce any discussion techniques.
• Gather input: Discuss what happened in the last sprint — considering both high and low points.
• Brainstorm ideas: Explore ideas for overcoming any known issues. Consider the flip side, too — recognize positive patterns to continue in future sprints.
• Pick solutions: Choose action items to implement in the next sprint.
• Close: Recap key points of the agile retrospective, summarize results, and share any notes with the team.

 

Agile retrospective notes template

Ready to get started? Download our simple agile retrospective template to frame your discussion. This template will help you structure your notes, document action items, and run a productive retrospective meeting. And when you need to change things up, explore more agile retrospective templates to spark engaging conversations.

FAQs about agile retrospectives

What kind of team should do retrospectives?

Reflecting on past work and identifying ways to improve is valuable for any type of team. Though retrospectives are most commonly associated with scrum teams — retros are the final scrum ceremony at the end of each sprint.

What are the benefits of retrospectives?

Holding regular retrospectives helps the team stay accountable, address issues quickly, and improve efficiency over time. Attendees of a retrospective meeting should freely raise concerns and offer potential solutions — so the entire team can make informed decisions about what to adjust for the next sprint. Retrospectives are a valuable opportunity to embrace the agile principles of adaptation, feedback, and incremental improvement.

Who should facilitate an agile retrospective?

While anyone on the team can lead a retrospective, the scrum master typically facilitates the meeting on scrum teams. If you are responsible for overseeing an agile retrospective, you can choose from a variety of frameworks and templets to help guide the discussion. Ensure that everyone feels heard, respected, and included.

How often should retrospectives occur?

Retrospectives usually occur at the end of each sprint. Depending on the methodology and release cadence your team uses, you might hold a retrospective every two, three, or four weeks. The length of the retrospective meeting itself will depend on the duration of the sprint, whether any unexpected problems arose, and team preferences. Most agile teams devote anywhere from 30 minutes to a few hours for each session.

What is the ideal outcome of a retrospective meeting?

By the end of each agile retrospective meeting, the team should agree on a list of action items to implement for the next sprint. Do your best to make every attendee feel valued and heard. This way, everyone leaves the retrospective motivated and focused on the upcoming work to be done.