Learn how Agile teams plan smarter—not longer—by using backlogs, story points, and prioritization to stay focused, flexible, and ready to deliver.

---

8.3.1: Backlog bricks and bits

In predictive project management, planning is often done in full before delivery begins. You set the scope, break it into tasks, assign resources, and schedule the lot. That approach works well when you’re confident in the deliverable and don’t expect much to change.

Agile flips that around. It assumes that change is likely, even expected, so the backlog helps teams plan in layers. It allows for detail where it’s needed now, and flexibility for what might change later.

Instead of locking in tasks months in advance, Agile teams focus on:

• Prioritizing what matters most today
• Leaving room to adapt as new information emerges
• Updating the backlog continuously based on feedback

Think of the backlog as your planning horizon—clear up close, fuzzier in the distance.

What goes into a backlog?

A backlog isn’t just a list of features awaiting development—it’s a tool for decision-making.

If you’ve worked with Agile software like Jira, Azure DevOps, or Trello, you’ve probably seen features organized into epics and initiatives. These are just different levels of detail—kind of like zooming in and out on a map.

• User stories are the most detailed—they describe a specific user need
• Features are the functional things we build to meet those needs. Features can also include:
  • Bug fixes – Items that maintain or improve the quality of what’s already built
  • Technical work – Things like system updates or architecture improvements
  • Chores – Low-priority internal tasks that still need tracking
• Epics group related features together—they represent larger chunks of value or capability
• Initiatives sit above epics and show how multiple epics contribute to a broader strategic goal

If you’ve come from a predictive project management background, you can think of this structure as a bit like a Work Breakdown Structure (WBS):

• Initiatives are like major deliverables
• Epics are like work packages
• Features and user stories are the tasks or outputs needed to complete them

The key difference is that in Agile, this hierarchy remains flexible and evolves as the team learns more. You don’t have to lock in the entire structure at the start—you build and adjust it as you go.

Who owns the backlog?

The product owner is responsible for maintaining the backlog, deciding what gets done next, and making sure it reflects the project’s goals.

In doing so, they speak on behalf of the people who will use or benefit from the product or service being developed.

In some projects, the product owner is the client (for example, in an internal project where the client is another department). In others, they act as a proxy, working closely with users and stakeholders to make sure their needs are understood and prioritized correctly.

Their job is to:

• Understand what users need
• Decide what the team should work on next
• Make sure the product delivers value
• Say “yes,” “no,” or “not now” to backlog items

They own the “what”, but not necessarily the “how.”

Who contributes to the backlog?

The product owner sources input from many places, but foremost from users.

In Agile, the whole point of planning in short cycles is to test, learn, and improve based on what real users say and do.

After each iteration or sprint, the team delivers something usable, gathers feedback from users, and adjusts the backlog accordingly. That feedback loop is what keeps the work focused on actual needs, not assumptions.

For example, if users consistently ignore a new feature or struggle to complete a task, that insight directly affects what gets prioritized next.

Then come other key voices.

• Delivery team members refine user stories, estimate effort, and flag technical considerations that help shape the scope of work
• Internal stakeholders—such as subject matter experts, service managers, or team leads—offer ideas or raise operational requirements the team might not be aware of
• External stakeholders—like funders, regulators, or partner organizations—might identify compliance needs, brand implications, or integration requirements

All of these voices matter, but they should always be considered through the lens of user value. A healthy backlog balances technical, strategic, and organizational needs, but always stays anchored in what users want and need most.

And not everything makes the cut. That’s where the parking lot comes in—a space for good ideas that aren’t a current priority but might return later.

A healthy backlog is always evolving

A useful backlog isn’t “set and forget.” It’s reviewed regularly, groomed for clarity, and reorganized as the project grows. In managing it, the product owner helps the team focus on the most valuable work, without getting lost in the noise.

In the next lesson, we’ll explore how to prioritize that work, because knowing what to do is one thing, but knowing what to do first is where the real planning power lies.

---

8.3.2: Prioritization

Once your backlog is up and running, the next challenge is deciding what to do first.

Agile isn’t about doing everything—it’s about doing the right things, in the right order, at the right time. That’s where prioritization comes in.

In Agile, the product owner is responsible for prioritizing the backlog. They make the final call on what gets done next, balancing user needs, stakeholder input, technical considerations, and business value. The rest of the team helps shape the conversation, but the product owner steers the direction.

MoSCoW: A practical way to prioritize

One of the simplest and most widely used prioritization tools is the MoSCoW method. It groups backlog items into four categories:

• Must have – Essential. Without these, the project fails or doesn’t function.
• Should have – Important, but not critical for launch. Can be scheduled for later.
• Could have – Nice-to-haves. Only included if time and resources allow.
• Won’t have (this time) – Out of scope for now. Log these in the parking lot for future review.

MoSCoW helps keep expectations realistic and visible. It also makes trade-offs easier to manage when timelines or capacity are tight.

Let’s say, for example, you’re working on a project to build an online booking system for a local community centre.

Here’s how you might apply MoSCoW:

• Must have – The ability to view availability, book a room, and receive confirmation
• Should have – Options for recurring bookings and calendar syncing
• Could have – Custom background themes for different events
• Won’t have – Multi-language support (not essential for this release, but worth revisiting)

By sorting features this way, the team stays focused on what users truly need—and avoids getting sidetracked by low-impact extras.

After all, if everything’s a priority, nothing is. Prioritization is how we protect value.

Why not just let everyone vote?

Some teams try to crowdsource priorities by asking users or stakeholders to vote on their favorite features.

That might seem democratic, but it’s not always effective. Here’s why:

• Popularity isn’t the same as importance
• Votes can be influenced by loud voices or short-term thinking
• Technical complexity and effort aren’t visible in a vote

Feedback is critical, but strategy and user value should drive decisions, not just popularity.

Prioritization is ongoing

Agile projects evolve, and so should your priorities. As new information emerges and feedback rolls in, the product owner reviews and adjusts the backlog regularly.

In fact, in many Agile projects, the backlog doesn’t shrink over time—it grows. That’s not a problem, it’s a sign that you’re learning.

As feedback rolls in, more ideas are generated, and priorities shift. The parking lot helps manage this by giving you a place to store good ideas without cluttering the current plan.

You don’t need to review the parking lot every sprint, but you should check in periodically, especially at key project milestones or when new phases are kicking off.

This approach is called rolling wave planning, where you plan near-term work in detail and leave future work flexible, refining it as you get closer. This allows you to stay focused on what’s important now, while still preparing for what’s ahead.

This is what we’ll explore in more detail in the next lesson.

---

8.3.3: Ready… set…

In predictive project management, you’ve already learned the difference between effort and duration. Just as a short task might be complex, a long task might be relatively easy once it gets going.

In Agile, we still need that distinction, but we apply it in a different way.

Agile estimation focuses on how much effort a task requires relative to other tasks. The idea isn’t to pin down exact timeframes—it’s to understand the size, complexity, and risk of each piece of work so the team can make smart decisions about what to do next.

Instead of predicting how many hours it will take or who will do it, Agile estimation asks: “Is this more or less effort than the last thing we did?”

The goal is to help teams:

• Prioritize work based on value and effort
• Spot potential risks or unknowns
• Balance their workload
• Forecast how much they can deliver over time

Introducing story points

Agile teams often estimate effort using story points—a unitless measure that expresses relative effort, not actual time.

Rather than saying, “This task will take 6 hours,” a team might say, “This feels like a 3-pointer compared to the 1-pointer we did yesterday.” It’s about the feel, not precision.

Many teams use a scale based on the Fibonacci sequence (1, 2, 3, 5, 8, 13…), which reflects that as tasks grow in size, the uncertainty grows too.

• 1 = Very simple, no surprises
• 3 = Moderate, a few steps involved
• 5 = Complex, some unknowns
• 8+ = Large or unclear—might need to be split

If something gets estimated as an 8 or 13, that’s often a signal it’s too big or too fuzzy. Break it down, ask questions, or do more research.

One of the most common methods for estimating story points is planning poker.

Here’s how it works:

1. The team discusses a user story or feature
2. Each team member privately chooses a point value
3. Everyone reveals their vote at the same time
4. If there’s a mismatch, the high and low estimators explain why
5. The group discusses, then votes again

This process surfaces assumptions, encourages discussion, and helps the team align around shared expectations.

From product owner to project manager

So, where does this leave the product owner and the project manager?

As we covered in earlier lessons, the product owner is responsible for deciding what gets done and why. They prioritize the backlog based on user value and stakeholder needs.

But once estimation begins, the project manager steps in to help shape how the work will happen.

Here’s how the handover usually works:

1. The product owner identifies and prioritizes stories or features
2. The team estimates effort using story points
3. The project manager uses those estimates to:
   • Forecast timelines and resource needs
   • Coordinate dependencies
   • Monitor delivery across sprints or project phases

In other words, the product owner drives value, and the project manager drives delivery. They work together, but with different responsibilities.

What’s a sprint?

You’ve heard the word come up a few times already, so let’s define it clearly.

A sprint is a short, fixed period of time (usually 1–4 weeks) where the team focuses on delivering a set of high-priority items from the backlog. It’s a core part of Agile delivery.

At the end of each sprint, the team should have something usable or testable—something that can generate feedback from users or stakeholders and guide the next round of planning.

Sprint planning, reviews, and retrospectives help ensure continuous improvement throughout the project.

Effort estimation, including story points, is used to plan how much work can reasonably fit into a sprint, based on the team’s capacity and past performance.

As teams complete sprints, they track how many story points they finish. This is called their velocity.

If a team typically completes 20 points per sprint, and there are 100 points left in the backlog, the project manager might forecast five sprints remaining, adjusting as needed based on new information.

Velocity isn’t perfect, but it provides a realistic, evidence-based way to plan over time.

In the starting blocks

With estimation complete, we’ve reached a key milestone in the Agile process: the point where planning hands over to delivery.

By now, we’ve:

• Clarified the vision so we know the outcomes we’re working toward
• Captured potential work in a structured backlog
• Prioritized that backlog based on user value and strategic need
• Estimated the relative effort of each item to support realistic planning

With this foundation in place, the team is ready to start work.

The product owner has defined what matters most. The project manager has enough information to coordinate resources and manage delivery. And the team knows what’s coming up, how big each piece feels, and what can realistically be delivered in the next sprint.

This is where Agile shifts from planning to doing—one sprint at a time.

Up next, we’ll launch into that delivery cycle and explore how Agile teams bring the backlog to life.