When I arrived at a startup software division, the story-writing process was virtually stalled. A young woman with a strong personality and backed by the authority of her executive father was vying for control with the more experienced Pharmacy Technician that was charged with supplying User Stories to the development team. The female tech, acting in the Product Owner role, liked the younger woman and even considered herself the junior’s mentor, but the tug-of-war against the stronger personality impeded progress.
As someone with significant project scar tissue, I was inserted as Sr. Business Analyst and was able to help them break the logjam. To the younger woman, I became the keeper of the product backlog and her story reviewer. She could submit detailed written stories of interest that I could include in the product backlog. To the more experienced tech, I became a sounding board for her more verbal approach to story writing. She wanted a partner to bounce ideas off of and someone to validate her own thinking before submitting a story in writing.
What made me effective in a situation where two others were stalled? I respected and agreed with both of them and refused to lock horns with either party. Instead, I offered gentle suggestions here and there, allowing each of them to write stories from their own perspective. I have learned that it is much easier to say ‘yes’ to feature requests than argue about them up front. Customers have limited budgets and limited time. In the end, it is these larger constraints that determine which features get included in a product. The most valuable features tend to bubble up in the list of priorities and get worked on. The least valuable often sink down and fade into oblivion. After all, a product backlog does not have to be empty when the project is done.