On Youtube you can find a small film by Henrik Kniberg on Product Backlogs and how they come to be. His small film holds a lot of the inspiration for the course/workshop I'm designing about Agile Requirements. (you should definitely watch it: https://www.youtube.com/watch?v=502ILHjX9EE)
When we look at Agile product development (including the software; at least in my case), a lot of information is available about the Software Development team and how they should to their work. Very practical information about how and when to do standups, how to keep continuously improving, how to plan development cycles, even on how to write code and test it. Very little, however, is said about the process to come to a set of requirements. It's not so strange then that this is the biggest struggle in most companies I coach.
In this blog post I will give you a first glimpse of the content of my Agile Requirements training. Please do feel free to comment; this is in fact my first sprint and getting the product out there means I can get the feedback loop going ;)
Every product starts with a vision. What problem is the product going to solve? What value is the product going to generate? What pain will the product take away?
The Product Backlog is the repository of all the functions, features, items, everything that makes up the Product. If something is on the Product Backlog, it might get done. If it is not, it most certainly will not.
We have found the User Stories are a good way to capture the functional requirements of the product. They are inspiring, concise and can easily be written by non-technical people. This is kind of the practical part of the course: How do I capture requirements in such a way that they fit in the Agile process?
Since we know that planning isn't an exact science, Agile does not pretend that it is. We don't plan in hours, days, weeks since a complex process like Software Development simply doesn't work that way. Story points are the measurement of all factors that lead to development time (size, complexity, dependencies, testability, architectural impact, you name it!)
Using the Product Backlog, it's user stories, their story points and the teams velocity, we can plan when any feature will be delivered. Approximately. Assuming everything stays the same. And if not, well, we'll adapt.
The last part of the course will focus on a very powerful tool: Story Mapping can give a high level overview of the total vision of the product. It can help give an idea of dependencies but also of the Minimal Viable Product and what that's going to look like.
Combine all these parts and the Product Owner has a large pallet of tools to help him in his work. Much like Pair Programming and Test Driven Development for the Software Developers, do these topics give strong guidelines on how the Product Owner and his stakeholders can do their work in such a way that the product benefits the most.
Are you already a Product Owner? Or a coach helping out a Product Owner? Please let me know how you approach these topics. Are all of these topics covered in your daily work? Are there important topics missing here (do remember though; this is a tooling training. Stakeholder Management, for example, is very important but not a part of the tooling ;))