Signing on for agile development includes its own Client-side Responsibilities

Agile is Cynerge’s preferred project management methodology, which involves breaking down large development projects into more manageable iterations, called sprints, within a predefined time period. Though there are numerous benefits, including an increase in productivity and quality, one of the most appealing is the direct and daily participation of the client product owner from start to finish. This allows us to get to know you, your business, its processes, and also helps us to feel the client is “in the trenches” and committed to the product’s success.  

While every project is different, most agile development frameworks will follow (more or less) a similar process with similar roles and responsibilities. For this article, we’ll focus on what it means to be a client-side product owner.

Role expectations

Having predefined roles, and an understanding of the roles involved, is the basis for an effective agile framework. When a client agrees to working in an agile fashion, it’s important to understand what it is you are agreeing to. One of the “terms”, so to speak, is that the client needs to designate a product owner. It’s the job of this product owner to represent the organization’s vision, requirements, and ensure this is reflected in the end product or solution. This role is a daily commitment and comes with the responsibility of serving as the link between the client and the development team. More specifically, these responsibilities include having an extensive understanding of the product, its vision, and the current market trends. You’ll help prioritize work in the product backlog, make decisions for the product on behalf of the client, and answer any questions regarding implementation. In other words, you’ll have final authority and decision-making power for the project.  

Product Owner in Practice: A Step-by-Step Approach

Backlog Refinement

During backlog refinement, this is where you define the features, requirements, and functionality of your project or product, as well as the definition of “done”. Here, as product owner, your input is invaluable as we incorporate your wants, needs, and user stories, or features your users would like to see, into one workable project. Once complete, we work with you to prioritize these requests in our backlog column. As each user story is completed through design and development, it will be sent to you for the final review and signoff on the staging server before release to production.

Sprint Planning

Now that your product’s requirements have been defined, we need to know how long it will take to complete. Everything is taken into consideration when estimating time to project completion. From our current burndown metrics or how many story points we can expect a team to complete during a sprint, to the prioritization of tasks set forth by the product owner, down to upcoming holidays or planned vacations, everything that could impact our work in progress is considered. The sprint planning session is usually a time commitment of no longer than two hours and largely involves negotiation between what is requested and what is feasible. Human-centered design features, expectations, and branding are usually discussed here. At the conclusion of the sprint planning, all parties involved will have a reasonable expectation of the number of sprints involved and the timeframe of product completion.

Sprint Standups

Communication and collaboration between the product owner and scrum master, and scrum master and scrum team, or development and design team, is critical to the success of the project. As a result, short 15-minute daily meetings, or standups, give attendees an overview of what was completed yesterday, what will be completed today, and any issues – called blockers – that need to be addressed. These take place daily for the duration of the sprint. Ideally, the product owner will attend as many standups as possible, since most early blockers require additional user research. This communication is vital, as any one issue not immediately addressed can set the whole team and project behind.

Sprint Retrospective

At the end of each sprint, after the work has been completed and the most recent iteration of a product has been successfully deployed, we have what is called a retrospective. During the retrospective, we evaluate the team dynamic, what worked well, improvements that need to be made, and any new avenues to explore. These could include everything from a virtual whiteboard conference with the client to collaborative peer reviews to changing a meeting time to improve attendance. Each one of these retrospectives is carefully logged after receiving the entire team’s input and then stored in our documentation for future research purposes.  

 What Can I Expect During Each Sprint?

As a product owner, you can expect to be presented with a working MVP, or minimal viable product, that is fully tested and vetted to put in the hands of real-world users every two to four weeks. Whether that specific sprint focused on the integration of a new geospatial mapping service, or being presented with high-fidelity mockups for approval, the sprint process will repeat until the ultimate competition of the project to the satisfaction of the product owner.   

 END GOAL

Embracing agile development methods can decrease costs, time to market, and drive product quality, while also promoting team cohesion and morale for those creating or maintaining the solution. Utilizing a framework involving short bursts of activity allows us to be more adaptive and responsive throughout the development process to changes or new priorities. Even though agile can be an extensive time commitment for a product owner, it affords the client more visibility and hands-on control toward the product’s outcome.