Learn how to kick off your Agile project with purpose—build a clear vision, find user stories, and set up your backlog for real value, not just busywork.

---

8.2.1: Vision

If you’ve completed Module 1, you’ll remember the process of project initiation—turning an idea into something structured and ready for planning. You’ve already seen tools like the project pitch, business case, and project charter.

The good news? These tools are just as helpful in Agile projects as they are in predictive ones. In fact, they may be even more important.

Why? Because in Agile, we usually don’t start with a detailed plan or a crystal-clear picture of the final product. That’s not a flaw—it’s intentional. Agile is built for uncertainty.

To navigate that uncertainty with purpose, the one thing we do need upfront is a clear, shared vision.

Would you be surprised to learn that many Agile projects begin without knowing exactly what the end result will look like? That’s not a problem—if everyone agrees on the direction.

Think of Agile like planning a trip where you know the destination, but you’re flexible on the route. You don’t need step-by-step directions on Day 1, but you do need to know where you’re headed.

That’s what the vision does. It gives your team and stakeholders a common understanding of:

• What problem you’re solving
• Who you’re solving it for
• Why it matters
• What kind of solution you’re aiming for (even if the details change)

In predictive projects, success often means delivering to scope. In Agile, it’s more about delivering value. That’s why vision is such a key part of getting started.

Here’s a quick example: when Apple began working on the first iPhone, did they know what version 5 or 10 would look like? Not likely. But they had a clear vision that guided their decisions, even as the product evolved far beyond the original concept.

The same principle applies to your projects. A strong vision gives you direction, helps with prioritization, and keeps everyone aligned, especially when choices get tough.

So, how do you write one?

Try using this simple structure:

• For… (target users)
• Who are dissatisfied with… (current situation or alternative)
• The… (project name) is a… (product type or category)
• That provides… (key benefits)
• Unlike… (similar or competing products)

Here’s a sample:

• For frontline staff in community outreach
• Who are dissatisfied with slow, inconsistent reporting
• The RapidTrack project is a lightweight mobile tool
• That provides fast, on-the-go data capture
• Unlike bulky desktop forms that slow things down

When broken into parts, this kind of vision statement makes the project’s purpose clear and relatable, without locking in details that aren’t ready yet.

Here are a few more tips to help you craft a strong vision:

• Focus on outcomes, not features. It’s not a checklist—it’s about value.
• Use plain language. Say it in a way real people will understand.
• Test it with stakeholders. If they can’t repeat it, it needs work.
• Use it as a guide. When you’re deciding what to build next, ask: Does it serve the vision?

As your project moves forward, the vision should remain your anchor—your compass in uncertain territory.

You don’t need to predict every detail. You just need to make sure everyone’s heading in the same direction, with purpose.

---

8.2.2: User stories

If the vision tells you where you’re going, user stories help you figure out how to get there. They’re the building blocks of Agile work, keeping your team focused on the people who matter most—your users.

User stories are short, simple statements that describe something a user needs or wants from the system you’re building. They’re written from the user’s perspective and explain the who, what, and why behind a task.

Each one follows a basic format:

• As a <type of user>,
• I want <some goal>,
• So that <some reason>.

Here’s what that structure tells us:

• “As a…” defines the user—maybe a customer, staff member, or community partner
• “I want…” spells out what they need
• “So that…” explains why it matters

A practical example:

• As a case manager,
• I want to upload client documents securely from my tablet,
• So that I don’t have to wait until I’m back in the office to complete paperwork.

Same project, different perspective:

• As a compliance officer,
• I want all uploaded documents to be time-stamped and securely stored,
• So that I can ensure our reporting meets audit requirements.

These aren’t technical specs. They capture needs in human language that the whole team can understand, regardless of their technical background.

So why use user stories?

• They keep the spotlight on real user needs, not just system features
• They make big goals more manageable
• They support prioritization—you can see what matters most
• And they spark conversations, which often lead to better solutions

User stories also pave the way for the next step: features. Once a user story is agreed on, it often becomes a feature in your project backlog.

But not every user story is ready to go. Here are a few tips for writing better ones:

1. Keep them small and specific—avoid wish lists
2. Use plain language—ditch the jargon
3. Make them testable—you should be able to say when it’s done
4. Write them collaboratively—with real input from users or their proxies
5. Check the vision—if it doesn’t support your project’s goal, leave it out

In the next lesson, we’ll look at how these stories become features and how they shape the work your team delivers.

But for now, take a moment to think:

• Who are the key users in your project?
• What might they say they want?
• And how would you write their needs as user stories?

If you can start answering those questions, you’re already thinking like an Agile project manager!

---

8.2.3: Featuring the backlog

In plain English, a feature is something the user can see, use, or benefit from. You can think of features as the bridge between what the user wants and what the team builds.

It’s the functional output that comes from fulfilling a user story.

Let’s revisit the user story we used earlier:

• As a case manager,
• I want to upload client documents securely from my tablet,
• So that I don’t have to wait until I’m back in the office to complete paperwork.

The feature here might be:

• Mobile document upload with secure storage and offline syncing.

Can you see how a feature is more specific than a story?

The user story describes a need from the user’s point of view. The feature is the thing we’re building to meet that need.

What counts as a feature?

In Agile, we use the word “feature” pretty broadly. A feature could be:

• A brand-new capability (like adding a mobile upload option)
• An enhancement to something that already exists (like improving load times)
• A bug fix or technical improvement that helps the system run better
• Even a behind-the-scenes change, if it delivers value to the user or supports project outcomes

That’s why features are also sometimes called initiatives, outputs, or even backlog items. What matters most is that every feature can be traced back to something that supports the project vision or fulfills a user need.

The backlog

As you build out your Agile project, these features form what’s called the product backlog—a prioritized list of all the work the team might take on.

But not everything you think of—or that someone requests—goes into the backlog automatically. Agile is about focus and value, not collecting every idea just in case.

Here are some useful checks to apply:

• Does the feature support the project vision?
• Is it linked to a real user story?
• Will it provide value if delivered?
• Is the timing right to build it now, or should it wait?

If the answer to all those is yes, then it’s a strong candidate for the backlog. If not, it might belong in the parking lot (the list of things we’re not doing—at least not yet).

That’s because a common challenge in Agile is that teams get excited and start adding features that seem interesting or useful but don’t actually connect to the project’s purpose. This is sometimes called feature creep, and it can be a real problem.

To stay on track, make it a habit to regularly ask: “How does this feature help us achieve the outcomes we agreed on at the start?”

If you can’t answer that clearly, the feature might not belong in the project right now.

In the next lesson, we’ll talk about critical success factors in Agile initiation—what makes the difference between a strong start and a shaky one. But for now, your takeaway is this:

The best features don’t just fill a backlog—they move your project toward its purpose.

---

8.2.4: Critical success factors

Let’s be clear—Agile doesn’t mean “just start and figure it out later.” Agile teams still need to set up the project properly. And that means getting a few key things right from the very beginning.

Agile doesn’t mean skipping planning. It means planning just enough to move forward, while staying open to change.

As with predictive approaches to project management, the better your start, the stronger your finish.