Vivian was the Scrum master for team Condor, that was responsible for managing and enhancing the customer insights platform for an FMCG major.
The newly formed ‘Digital Surround’ team under marketing was their main user department.
They had very ambitious plans to introduce a lot of functionality in the customer profiling and targeted marketing initiatives, that needed the Condor team to implement many enhancements to the platform.
Byomakesh, the Senior tech lead who was also playing the role of the architect had his list of enhancements to be implemented to make the application scalable and extensible for the future needs, as he could extrapolate what the next set of functionalities are likely to be.
But, the Product Owner, from the marketing team was insistent that only functional stories be taken up, as they had a huge wish list and almost all of them were high priority to be done immediately.
While there was still a good 8 months to the big holiday season, Vivian knew that he cannot accommodate all the requests.
But his challenge was to have a prioritized backlog that included the expectations from not only the business user, but also the architect, which the team work on clearing as soon as possible
What can Vivian do?
Share your recommendations as comments to this post.
Suggested Solution
The key to address this challenge is to have a common understanding of priorities between the Product Owner and the team that might come up with technical stories.
While the business value is a commonly used weightage parameter, it is many times difficult to assign a clear value, particularly for technical stories that might be infrastructural by nature.
Techniques such as the Weighted Shortest Job First is slowly gaining popularity, but may take some time for the teams to internalize the concepts.
An adaptation of that is to look at the lead time to deliver a feature.
If there are dependencies on technical stories to implement a functional story, that should be clearly brought out and the linkages established, before getting into a release planning session.
In other words, the impact on the schedule can be a simple approach.
Another could be based on assigning a weightage to the technical debt incurred.
if the debt were to be cleared later, the cost will increase.
even a simple linear model [while an exponential model is better] would work.
Or, use the Fibonacci sequence over time [every release window] to increase the cost of servicing the technical debt.
What techniques have worked for you?
2 Responses
While the solution is simple, its implementation will be tough since the business would not easily sponsor them. While it is a good idea to write all technical debt stories, generally, there will not be any Product Owner who likes to own and accept since the PO comes with business mindset. These kind of work is pushed by external team (not the scrum team). Generally, these is a lack of ownership of these stories and pushed by external teams. I am purposefully, I am not the solution this gap in this comment. Want to hear from others.
I agree Guru. The reason why i mentioned this as a Dilemma for the Engineering manager is do we handle only the low hanging fruits and run with it, or would you work for a harder and more difficult transformation of creation of a working pipeline.
I know one manager I have interacted made the call and felt the next 6 months extremely hard to convince and influence different stakeholders. This is easier to accept while you are doing a transformation.