Meet the Team
This course was created by three dedicated contributors.
Patrick O'Malley, an executive-level Chief Product Officer for online businesses, wrote the original course content, bringing his extensive experience and expertise.
Romain Dassy, a freelance Product Manager and Technical Referent at OpenClassrooms, played a crucial role in updating and refining the course.
You'll also see Kevin Moran, an IT professional, as he guides you through the videos with clear and engaging instruction.
Together they’ve crafted this comprehensive and accessible course to help you master agile documentation.
Key Concepts
There are nearly as many ways of handling agile requirements as ways to be agile. This course presents some techniques that you may find useful in your work; however, many other tools exist, and there are very few, if any, best practices regarding agile requirements. Here are a few terms and variations to be aware of as you learn and go through the course.
User stories vs. Product Backlog Items
A user story is a specific type of Product Backlog Item in Scrum. Many others exist, and the formats for expressing those PBI’s can and should vary. Other PBI’s include tasks, bugs, defects, research items, analysis work, infrastructure work, scalability changes, security work, etc.
Product manager vs. product owner vs. other names
In this course, we will refer to a Product Manager. It is important to note that there is a difference between a product manager and a project manager. There is also sometimes a difference between a Product Manager and a Product Owner. If your organization uses Scrum, you may be more familiar with the term Product Owner.
Regardless of how your organization defines this title, it helps to understand what they are responsible for, accountable for, and how much authority and autonomy they possess around the product.
Requirement workshops vs. other techniques
When I started my career, JAD sessions were popular. These were joint application development sessions, and they looked and sounded a lot like the requirements workshops in this course. They can also be called workshops, sessions, huddles, or just conversations.
It doesn't matter what you call them as long as they are flexible, customer-focused, and include the people who need the solution and the people creating the solution. I like “requirement elicitation” because you want to discuss a customer’s needs, elicit some actions we can take, and hopefully create a valuable product or solution for them.
Requirement gathering is usually a data collection technique where you ask people to submit what they want at the beginning of a project. It is not in the spirit of agility and will likely lead to a more difficult project or product lifecycle.
Feel free to come back to this page as you go through the course to reference these key words and key distinctions. Now that that's out of the way, let's get started with the course!
