Foreword
Connie Heidenreich, PSM, CSM, CSPO, SAFe Agilist, ICP-ATF
Agile Coaching and consulting became her calling. Her span of experience includes helping organizations transform into Agile, establishing new agile start-up teams, as well as working with mature companies and teams to better their processes. The bumps and bruises collected along the way have brought her to the realization that helping organizations adopt Agile practices was less about the practices, and more about embracing change.
We are proud to count Connie as a key member of the SDS team, and value her expertise as an agile coach and scrum master.
~David Pledger, Managing Partner, Strategic Data Systems
Introduction
If you are familiar with many of the agile frameworks (Scrum, Kanban, SAFe, etc), you’ve probably come to appreciate how critical the relationship is between the team’s Scrum Master and the Product Owner. However, I can personally relay that the relationship between the Product Owner and the Agile Team is just as important if not more crucial to the team’s success. Read on for a few reasons why!
One of the major responsibilities of the Product Owner is to have a vision of what is to be built and convey that vision to the Agile Team. This is key to successfully beginning any agile software development product. The Product Owner should first do this by adding features to the product backlog, which is a prioritized list for the product. It is then up to the agile team to take that information, break the prioritized features down into workable stories that are small enough to fit into a sprint, and build the product through incremental design and development. All the while they are obtaining consistent and timely feedback from the Product Owner. Easier said than done, right?
To give more background on the Product Owner, let’s look at their typical persona. They are commonly a lead user of the system or the product being built. They sometimes are someone from marketing or really anyone with a good understanding of the users, the competition and of the future trends for the type of system being developed. This, of course, can vary tremendously based on whether the team is developing software for internal or external use, hardware or some other type of product. The key however is that the person in the Product Owner role needs to have a clear vision for what is to be built, be able to relay that effectively to the team and be available to the team for feedback. In this role, the Product Owner should be both business savvy (understand the “what’) and technical (be able to explain the “what”) but let the team decide how to do it.
How the product backlog get's built.
As I mentioned earlier, the Product Owner starts out building ideas about the desired product by adding features to the product backlog. The features can and should include both “requirements” and “desirements” from all stakeholders, including the Product Owner. Though the Product Owner is responsible for building the backlog, to ensure it is representative of all users, they should include feedback and requests from all stakeholders and be able to anticipate client needs. The ranking of each request should be regularly reviewed to ensure it reflects current priorities and needs. They should also remember that the product backlog is emergent, meaning that it is constantly in a development state, ever-changing, with items being added, removed, and even altered.
How the team and the product owner work together.
1) Sprint Planning
Although the Product Owner is the one in charge of prioritizing the product backlog, it is the team that selects the amount of work they believe they can do during each sprint. The Product Owner prioritizes the backlog by placing the most valuable items at the top and the least valuable at the bottom. Before the team sprint commitments take place in sprint planning, a transparent discussion should occur between the Product Owner and the team that includes details on the most valuable items, what is required to deliver a desirable outcome, and any foreseen impediments standing in the way. Based on this information, the team then breaks down a few of the most valuable items into workable stories and decides how much effort is required to get each story done. In return for the team's sprint commitment to completing the selected user stories from the top of the product backlog, the Product Owner should make a mutual commitment to not throw new requirements at the team during the sprint. Requirements can change, and change is encouraged, but only outside the sprint. Once the team starts on a sprint, it will remain super-focused on the goal of that sprint.
2) Team Empowerment
What’s also important to understand is that the team should feel empowered to make story sizing efforts on their own, without any influence from the Product Owner. The team knows their dynamics best and they know what is needed from the entire team to get the story done. The team members know what they are capable of and they are the ones skilled to select which stories they can commit to delivering for the sprint. The Product Owner does not have the power to say, “This story can’t possibly be an 8 in effort, I could do it myself and it would be a 3.” The Product Owner's job is to motivate the team with a clear, inspiring objective. The sizing of the work, how much work can be pulled into the sprint, and how to do the work should be trusted with the team to decide since they are the ones actually working on it.
3) Product Owner Empowerment
The Product Owner must also be given the formal power to own and manage the product backlog. This may seem obvious, but I have observed many situations where the Product Owner neither has the formal or informal power. For example, there sometimes is a struggle between the business and technology owners of the application. Sometimes technology upgrades or other non-functional requirements are maintained outside the backlog. Or, there may be multiple business organizations that refuse to yield power and control to the Product Owner. In these cases, there may be several backlogs, none of which are visible or transparent. The team is then confronted with conflicting demands and priorities. The Product Owner should feel empowered to act as the primary liaison between technology and business groups and the team. Without a rank ordered list, it is unlikely the team will be able to stay focused and maximize the value of the product they are building and supporting. Granting the Product Owner the formal power to manage the backlog can be difficult. It sometimes requires challenging existing power structures in the organization or dismantling silos within the organization. It can also irritate executives that don’t full appreciate the agile process and want to champion their own causes. However, for agile to be truly successful, these changes are necessary.
4) Continuous Feedback
The Product Owner role requires an individual with certain skills and traits, business savvy and communication skills. However, first and foremost, the Product Owner needs to be available to the team for questions, discussion and continuous feedback. The best Product Owners show commitment by doing whatever is necessary to build the best product possible and that means being available and being actively engaged with their teams. Product Owners do this during sprint planning, during the sprint review, but most importantly, while the sprint is in session and anytime the team needs them. A Product Owner will most certainly be involved in many meetings; however, they should remain visible to the team. For product development to be successful, consistent feedback from the Product Owner is imperative. Product Owners demonstrate commitment to the product by being available and engaged throughout the development cycle.
Conclusion
As you’ve come to see, one of the secrets to becoming a high-performing team is the relationship between the Product Owner and the Agile Team. Teams work most effectively when a Product Owner knows the product well, owns the priority of the backlog, communicates their knowledge responsively and decisively, and there is mutual respect and empowerment between both parties.
Next Steps
Want to learn more? SDS can assist you in several ways:
- Schedule a Lunch-and-Learn tailored to your specific questions.
- Attend the annual Cincy Deliver conference on the last Friday in July. Organized by our agile expert, Phil Japikse, Cincy Deliver focuses on developing software, which includes agile methods. (https://www.dayofagile.com )
- Ask about or transition and mentorship programs.
- Consider working with a blended team consisting of your people working side-by-side with experienced agile developers on a project.
Contact Steve Held at Steve.Held@SDS.io or 513-218-1706 for more information.
About Strategic Data Systems
Strategic Data Systems helps business adopt technology.
We believe that letting us do what we do best—Technology—allows you to focus on what you do best.
We believe companies who can efficiently produce, process, find, and consume critical information at the exact time it is needed have a significant competitive advantage over those who cannot.
We believe information sharing among employees has great value and that highly collaborative teams enhance individual performances.
We drive business success using technology solutions.
We provide these solutions as a professional services organization providing offsite IT project execution, consulting services, system integration, and staffing services.
Visit http://sds.io for more information
