Traditionally confined to creating hefty upfront requirements documents, BAs find themselves at a crossroads in the Agile world. However, we believe BAs hold the key to promoting agility and delivering maximum value to organizations.

In this episode, we challenge the notion that BAs are mere translators of requirements into user stories. Instead, we highlight the rich business knowledge and questioning skills that BAs possess. By delving deep into business processes and understanding the "why" behind them, BAs can unearth genuine value in user stories.

BAs also have the unique opportunity to uncover hidden needs and facilitate cross-functional dialogues that drive process improvements. By fostering collaboration and aligning business objectives with software development, BAs can contribute to the creation of software that not only meets user needs but also enhances overall organizational efficiency.

In the year and a half that the Agile Bites podcast has been around, we've covered a lot of topics—from story points to stand-ups to MVPs and a whole lot more. And we hope it's been a helpful resource in our listeners' Agile journeys.

Now, we're taking a look at the future and asking ourselves, "What's next?" Listen to this episode to hear from Host Phil Ledgerwood about the new direction of Agile Bites, and we'd love for you to be a part of it by leaving your feedback! Leave a comment on this platform or email Phil at [email protected].

If we had a dollar for every piece of “authoritative Agile advice” out there, let's just say that we'd have a lot of money.

Sharing the successes, failures, and lessons learned is so valuable to all of us on an Agile journey. But it's important to keep your filter up for not only false information, but also true information that doesn't fit your situation.

In this episode, Host Phil Ledgerwood dissects some “authoritative” facts and figures about so-called “full Scrum” vs. “lightweight Scrum” to demonstrate how easy it can be to fall into the trap of misleading Agile guidance.

The lesson here? Don’t blindly accept what anyone says, no matter the source (even this podcast!). Always investigate, weigh it carefully, and experiment for yourself.

Traditionally, QA has been synonymous with manual testing and has been established as its own post-development phase. But in an agile landscape, that setup can lead to bottlenecks and silos. That's why we advocate for making QA a strategic player throughout the entire development journey—not just at the end of development.

Tune in to gain insights on reshaping QA practices and maximizing its impact on the entire value stream of software development.

We all know we should get user stories as small as they can be, but can we go too far?

Yes, user stories should be as small as we can get them, but they also need to be a valuable delivery (e.g. a user story should not just be a technical task).

Tune into this episode for actionable tips on what to do (and what not to do) to keep your user stories both small and valuable.

Have you or someone you know ever been stuck with pages of requirements notes having to turn those into user story format (As a [persona], I [want to], [so that])?

If so, first of all, we're sorry. Secondly, we want to help you know that there are other—and better—ways to dealing with this situation, and that's what this episode is all about.

User stories should be user STORIES—pigeonholing them into a one-size-fits-all format takes away from the value they were meant to provide. Tune into this episode to hear a brief history of user stories and get back to the WHY behind them so that your user stories function the way they're supposed to.

You might be wondering what this controversial subject has to do with agility, but people in the agile community are already trying to figure out how this topic works in an agile environment.

How do we reconcile with the work-from-home debate when one of the principles of the Agile Manifesto is that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation?”

Ultimately, just like anything else, this is something that is heavily dependent on context and is a decision each organization needs to make. But this episode lays out the realities of both dispersed and co-located teams and presents ways to approach this topic from an agile perspective.

When you ask how long a project is going to take, do you ever feel like your developer team is telling you what you want to hear rather than reality?

Unfortunately, this problem is all too common in software development when it comes to estimating deadlines and giving progress updates. We're not claiming it's anything nefarious—humans are just bad at predicting how long things are going to take (especially when building a huge project for the first time) and they probably just want to keep you happy.

In this episode, learn what signs to look for if you're being lied to, why teams feel like they need to lie, and how to prevent a culture that incentivizes it.

So you've defined success for your MVP. But have you thought about how you're going to measure whether it's successful or not? It sounds simple, but it's often not.

Some measurements are black-and-white and easier to extract information from. But others (like sentiment) have a lot more gray areas and can be tricky to make decisions based on.

In this last episode of our MVP series, learn about different types of measurements (financial, technical, operational, and psychological) and how to extract valuable data from even the trickiest of factors so you can make smart decisions about your product.

Next in line on MVP series, we're talking about defining success for your MVP.

The point of an MVP is not to create a small version of the product—it's to get meaningful information that will inform your decisions about the product going forward.Because of this, how you define success plays a vital role in whether your MVP reveals valuable information about your product's viability. 

What things, if they turned out to be true or false, would cause you to rethink this product or would convince you that you’re on the right track?

In this episode, learn about the different success indicators that can be considered and how to define those best so you can measure the valuable information to make informed decisions about your product's future.