If you are looking for a nice summary of the product owner role in a Scrum environment, I recommend checking out an article on nutcache.com ( http://www.nutcache.com/blog/what-is-scrum-methodology-and-project-management/ ). As I type this, I literally haven't read the post beyond the product owner description section because I wanted to jot down some thoughts. In particular, the potential parallels between the product owner role and the business analyst role.
As early as the first sentence in the product owner role description, you see where the two roles differ. The author states "The product owner is the one in charge of the business side of the project." I agree with this and some people might think this holds true for the BA role as well. Fortunately or unfortunately, the business analyst isn't in charge of squat. In many cases, we struggle to control the methods we use to do the job, the work products we use, what tools we can use or the acceptable format of our deliverables. I literally had a project manager tell me once that she wasn't sure she would allow me to speak in a requirements meeting she was driving. This is not uncommon when a BA is assigned to a project that is underway and that project is perceived as struggling. All of this isn't necessarily a bad thing, it is just part of being a business analyst in a competitive workplace filled with capable people that might have strong personalities.
After that first sentence in the narrative however, the authors description of a capable product owner can easily match the same criteria for a capable business analyst. A business analyst that transitions to the product owner role may need to shore up their "take charge" skills. Although, taking charge of something on a Scrum team is normally quite different than taking charge of something in a waterfall environment. I would have to say that a business analyst is better suited for "taking charge" in a scrum environment than in a waterfall one. It all comes down to three words why this is true, “the product backlog.”
Any business analyst that is capable of managing a robust requirements package should find product owner backlog management an easy transition. They are not the same but they are really close! A well crafted requirements traceability matrix (RTM) can often be directly imported into a product backlog, particularly if that was the intention all along (hybrid environments). A business requirements document (BRD) is basically a product backlog with chunks of narrative in between.
Now I would like to pivot to the last sentence in the articles discussion on the product owner. This is because this sentence could be lifted directly out of the product owner context and placed into the business analyst context without a quite little modification.
That sentence reads, "To effectively function in this role, it is paramount the PO come equipped with great business skills as this is pertinent for decision making and profitability actions."
© 2017 Dwayne Wright