The agile/SCRUM product owner (PO) is one of the most multi-faceted roles in technology methodologies today. Within a project, the PO is central in making the decisions and providing the details that keep the project team moving forward efficiently. And, of course, we’re not just interested in moving forward efficiently, but moving forward toward a set of deliverable software that creates value for our organizations. With that goal in mind, I’d like to take a step back and consider what responsibilities an agile product owner has, outside of the immediate project context, given the assumptions of the role within the agile/SCRUM methodology.
Project Responsibility #1: Product Owner makes good decisions about what to build within the time line of a sprint–i.e. the product owner provides day-today direction to the team.
Implications:
1) Comprehensive understanding of current capabilities. To make effective, sensible decisions about functionality within the context of the current business goals and everything else the system can currently do, the product owner must understand how that system works and what business processes it supports.
2) Obtain input from business stakeholders. It’s rare that a single person is the one and only stakeholder on a project. More often, there are a myriad of stakeholders, each concerned with specific goals and functionality. To make informed decisions, the product owner must be in touch with these goals and often must balance multiple perspectives.
Project Responsibility #2: Product Owner prioritizes the product backlog. This is the core of agile, without a prioritized backlog very little productive work happens.
Implications:
1) Insight into executive expectations. It’s rare that a member of the executive team holds the product owner role, so it’s critical the the product owner have a means of staying informed of business priorities, executive direction, and changing market conditions.
2) Understanding of IT architecture. Since the product owner calls the shots on what gets done first and what gets lumped on the bottom of the list, a proper steward of the organization’s resources needs to understand the architectural implications of these decisions. Pushing off the basics like upgrades and closing security loopholes in exchange for new functionality will eventually cause the system to crumble in on itself. I’m not saying this person should identify these technology needs, but they need to work closely enough with the enterprise architect to properly prioritize them.
3) In touch with the customer. While executive expectations and IT architecture important, understanding what the customer really needs (and will pay for) is critical in prioritization.
I think we can begin to see why Mike Cottmeyer is talking about a product owner team. This is certainly a diverse set of activities to place on the shoulders of one person. And this list does not include details of project-specific responsibilities to hammer out details like UI design and detailed acceptance tests, nor the set of activities for communicating back out to the organization about what the technology team is doing (or releasing).
Given all this, the Product Owner is, in my opinion, a pure bridger, ensuring the business and IT are working in lock-step alignment. With awareness and execution on the above set of responsibilities and a team of people to help support project-specific responsibilities, this role might just be what we’ve been looking for to truly “bridge the gap.”
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 5 comments… read them below or add one }
The Product Owner also needs to give final acceptance to whatever is built during each iteration/sprint. They have the final say on whether what was built actually matches their vision. Teams which do not have this step in place can find themselves in a difficult position during iteration/sprint demonstrations when functionality being demonstrated is not what stakeholders expected.
Thanks for the comment, Bob. I agree that’s a key responsibility and didn’t mean to overlook it…I just couldn’t think of any “outside the project” responsibilities it entailed. But definitely many “within the project” responsibilities and the potential to consume a great deal of time and effort.
Laura, it’s interesting because many teams think it isn’t within the project because it isn’t done “by the team” as they define it. Too often “team” is developers and testers and that is all. A Product Owner doing anything is considered “outside.”
It will also affect how the backlog is prioritized. Changes needing to be made based on what is and isn’t accepted for example.
Good post though. Glad to see your blog succeeding!
I see the perspective now, Bob. I was definitely thinking about any activities to define specific stories and help the team elicit the detailed requirements/test conditions as falling inside the project. But given your point, this line might be just about as arbitrary as any.
It does raise an interesting question, however, in terms of how teams set expectations for what can be done within a sprint and what needs to be a precursor….I’m still challenged to see how detailed requirements can effectively be defined within the same sprint they are being built…but maybe that’s me clinging to a piece of my waterfall/RUP hat!
Bookmarked for future reference