Struggling With Technical work
Over the past year, there have been a few technical stories that I've really struggled with as a product owner. First of all, I struggle to understand what they set out to accomplish. I also struggle to understand the value they provide and how to prioritize them amongst user-facing stories. But these issues aren't my main concern...
I've found that even after prioritizing the work, some of these stories have stretched out for many months before any value is realized, and they are consuming 1-2 members of the development team full-time. In one case, what was originally estimated to take 3 sprints, has ended up taking more than 20.
I've tried bringing up the importance of predictability in retrospectives and expressing my concerns. I've tried bringing the topic up with management. I've tried asking for ideas for action items on how we can improve. But it always ends in statements like, "we're doing the best we can, and these features are just really difficult features to work on."
At this point, I'm not sure what else I can do other than except that we will have technical stories that may take over a year to implement, and that they may extend well beyond their original predicted completion date.
Is there anything else I can do as a product owner to ensure we deliver value more quickly and to ensure we are more predictable and transparent?
One of the services of the Scrum Master to the Product Owner is ensuring that members of "the Scrum Team understand the need for clear and concise Product Backlog items". As a Product Owner, I can see two ways to approach this problem alongside the Scrum Master.
The first thing that I'd suggest is working with the Developers to make sure that if something goes into the Product Backlog, it's expressed in a way that stakeholders can understand. Even the most technical work can be expressed in how a change will do something like increase performance, increase maintainability or reduce maintenance costs, improve product quality, decrease the chance of regressions, or something. There may be an opportunity, perhaps in conjunction with the Scrum Master, to improve the Developers' understanding of the different stakeholder groups, the domain language, and what is considered valuable.
The other aspect is the conciseness of the Product Backlog Items. There isn't a whole lot of guidance regarding refinement and what it means for a Product Backlog Item to be ready for a Sprint, but "items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event". Perhaps there is a big chunk of work that can take many Sprints, but the Developers should spend some more time slicing the work up into smaller chunks to ensure that each chunk can be completed within a Sprint.
I'm struggling to think of anything that would take 20 Sprints to complete that can't be decomposed into much smaller chunks and expressed in a way that a stakeholder can understand why it's valuable.
we will have technical stories that may take over a year to implement
That's not what I'd call it. What you've got is a hidden waterfall project, for which empirical control is not even being considered. Why? And why is this stuff being parasitically attached to the work on your Product Backlog, the value of which you can account for?
@Thomas
Would you consider decomposing the technical story into 20 "arbitrary" PBIs to be an acceptable solution in this case? e.g. Technical story part 1, Technical story part 2, etc.
@Ian
My understanding is that it is not possible to break this particular story down into something that provides value, or is even able to be merged with the product, until after it is nearly complete. Unfortunately, I can't push back very hard on this since I've never been a developer, and I do not understand what is required to make the story happen.
Regarding your second question, we currently place technical work and user-facing work in the same backlog. Are you of the opinion that technical work should be handled in a different way? If so, please explain further.
Technical work has value just like feature work. In the case of feature work the value is negative as long as the work is not done and positive once it is completed. For technical work that is not different.
The value might not be customer facing. It could be something like "we have to upgrade our Continuous Integration engine to a version that is supported by the vendor". The value is derived from having support for the system should an problem arise. Or it could be "in order to deliver new features M, N, O, and P, we have to refactor the backend portion of our system that allows file uploads." The key is helping the technical staff to find and convey that type of information. They often will just see those as "upgrade something" or "refactor some code".
As a Product Owner you can question the technical team to discover this information. Try something as simple as the "5 Whys". This technical change is valuable why?
In the Scrum Guide the Product Backlog is described in this way:
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Single source of work means that any work, feature or technical driven, needs to exist in the same backlog. Separating them will cause more trouble than you can imagine. At least it did for me the one time I agreed to try it.
As @Thomas Owens said, I cannot think of anything that would require a year to complete that can't be broken down into smaller increments. I have completely rewrote applications in a new language in less than a year and was able to break that down into small increments of valuable deliverables. I think your technical organization is trying to take advantage of doing the work without due diligence in determining what the work is and by using your admitted limited knowledge to hide things. It might be because in the past it was hard to justify doing the work. But you have shown you are not opposed, you just need to know how to arrange all of the work so that the most valuable to the company is being done. Approach the team with that and promise them you are not trying to stop the technical work.
Being asked to prioritize something you don't understand seems an impossible task.
It appears there is a failure of transparency. As a minimum, if anyone wants you to prioritize anything, I'd say it's reasonable for you to expect they explain the various potential impacts of the choice to do it now, later or never.
Developers will have expertise in their field, but they don't have the same context as you, and like anyone, they are at risk of making decisions, based on false assumptions.
For instance, if technical work is needed to make your product scaleable, it might not be necessary to do that work now if you don't anticipate an increase in usage in the near future. Likewise, there may be functionality that developers consider important to refactor, but if that functionality is of low value, there may be alternative options, like removing the functionality altogether.
Transparency needs to go both ways in this process. If developers have a good understanding of the future direction of the product, they are also more likely to understand (and advise) which technical work is of sufficiently high value to be done now, later or never.
Would you consider decomposing the technical story into 20 "arbitrary" PBIs to be an acceptable solution in this case? e.g. Technical story part 1, Technical story part 2, etc.
In my view, you should steer well clear of arbitrary PBIs like this. They massively impede transparency.
Unless there is an inspectable result of a done item, such PBIs just become buckets of work, with an emphasis on the developer being busy by doing it, rather than empowering anyone to consider the effect of this work, whether prior assumptions were correct, and ultimately whether it makes sense to stop, continue, do more or do less on the initiative.
Would you consider decomposing the technical story into 20 "arbitrary" PBIs to be an acceptable solution in this case? e.g. Technical story part 1, Technical story part 2, etc.
The team needs a solid scrum master who can support them in "slicing thinly"
What that means if they are doing something like "moving all functions from SQL to Mongo" (replace those two products with whatever makes sense) is likely to be unique to your product.
If the customer doesn't care about the implementation detail then the tech team need to represent that to you in a way where the customer does care. The customer cares about security of their information - they don't care that your tech team wants to implement 2 factor authentication to achieve that security.
we currently place technical work and user-facing work in the same backlog. Are you of the opinion that technical work should be handled in a different way?
All the work a product requires should be accounted for and managed in the same Product Backlog.
My observation is that technical work actually is being handled in a different way in your case. It is listed in the Product Backlog...but you can neither account for or manage it. The transparency Scrum requires is absent.
If that technical work is being managed at all, it's currently a non-Scrum project. Its inclusion on the backlog for a product, the value of which is optimized Sprint by Sprint, leads to an obfustication which you are now experiencing.
Would you consider decomposing the technical story into 20 "arbitrary" PBIs to be an acceptable solution in this case? e.g. Technical story part 1, Technical story part 2, etc.
Probably not. Each slice should be deliverable, help the team ensure they are on the right track, and add some kind of value.
For me, it's very difficult to talk details without any details. It would be helpful to understand what these technical Product Backlog Items are, along with some context about the product being developed.