An Agile Product Backlog Is NOT a List of Requirements with Adam Ulery

This week, Dan Neumann is joined by his colleague and friend, Adam Ulery, to talk about product backlogs.

 

In this episode, Dan and Adam explore the recent patterns showing interesting ways of using Agile terms, as it is an example nowadays that people call product backlogs the source of requirements for the Team, they discuss today the challenges that may arise as a result of this misinterpretation.

 

Key Takeaways

What are product backlogs? And why they are not just the source of requirements.

A product backlog is a list of all the things that will be needed for product development.

If you consider product backlogs the source of requirements, then the only action that can be taken is to deliver them, not leaving any room for creativity or flexibility. No new alternatives seem to be welcomed if “the requirements” are already set.

The product backlog often grows when items are added (this is one main distinction from a list of requirements).

Where’s the commitment point?

Adam advises differing that commitment point as far into the future as possible so the Team can make the best decision that they can.

Don’t forget the learning component.

We are building to learn, always trying to learn and to use that knowledge to inform what we do next.

We always update our plans based on what we are learning.

Do Teams have to have a hierarchical structure with epic and features?

Adam explains how this became a trend over time.

There is a need to organize the work to show to the client, but when encountering unexpected work that needs to be done, it does not need to appear in the user story format since it is simply not valuable.

 

Mentioned in this Episode:

The Art of Prayer, Kenneth E. Hagin

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!