Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.
She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board – her customer who is first in that market seems to be changing their mind. The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration – given that the client is important and first in the segment.
What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.
Suggested Solution:
Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.
In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility – as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users / personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.
The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.
Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.
2 Responses
Yes. My experience is little different. Being in process quality for more than two decades we always speak of adherence to established management systems and miss the difficulties with the technical team. The same is the case with the techies too. We both were speaking different terminologies.A state of annoyance was always existing. They would want that we have to “wish them get lost” while we would be at a loss to understand as to why they run away from us. Luckily we were able to get a senior technical expert who had a flair for process management and the gap was bridged. Although our getting connected well is a slow process, we were able to make a progress. 🙂
Thank you Ramachandran! Developing a relationship whether at work or in any context is a slow dance in my experience. You take it one step at a time and slowly see how you move and what you create together.