Technical versus functional effort management

If those separate technical initiatives provide value, shouldn’t they have their own Product Owners who can account for that value and maximize it?

Yes Ian, the technical initiatives do provide vallue.

Part of the "challenge" in my current situation is how the teams are currently split.   We do not have a well-defined product structure identified; instead, teams are basically responsible for one or more applications.

Our IT management acts as a Technical Product Owner for such technical initiatives.   One recent example is moving all of our source code from one tool to another (better maintenance, organization, etc.).   Another example is moving our applications from one type of server to another (performance, support).   Another example is enhancing our auditing and log retrieval processes.

Such initiatives affect all teams, and the applications they support.   While they are critical to the business, they are mostly transparent to customers.   They mostly do not require coding changes, but do require extensive automated regression testing to ensure everything still works.

The concern I have is that the organization wants to now manage these efforts separately from the Product Owners (through a separate IT Technical intake maintained by IT management), but such efforts will still require work from the scrum teams.   

How are others managing similar situations?   Do others also work with two separate intakes into each development team?   If so, what are some suggested "better" practices or processes for making such an approach work well?

I am fairly new to scrum but I remember speaking to one guy in our org on the tech side and he has an arrangement with his product owner that tech has an allowance of up to 20% of each sprint for any necessary tech work that would be transparent but still valuable to the customer. Things like technical component patches, security updates, data optimization or quick-hit bug fixes would usually be candidates. If the 20% is not necessary, it does not carry over but when it is necessary, it is used. Obviously there has to be some flexibility in negotiations even with an agreement like this in place but I believe this arrangement has been working for them.

Thank you Russell.   That is one option being considered.   Curious if there are any other approaches out there.   Even leaning about ones that failed would save me the effort exploring them.

The Development Team are accountable for technical robustness, sustainability and standards even though these things are not always of immediate value to a Product Owner.

Hence it is certainly within the gift of a Development Team to “reserve” Sprint capacity to take care of such matters. However it may not be reasonable to fix this to a set percentage without evidence that the amortization rate will be optimal. It may be better for the team to make a rolling forecast of their projected capacity, Sprint by Sprint, based upon what they think will actually need reserving in each case. The challenge ought to be making that work sufficiently transparent, not agreeing if the team can do it within an “allowance”.

In early Sprints, when architectural foundations are often established, comparatively little feature functionality may be delivered. The team reserve the capacity they need while undertaking to deliver an increment of value, however small, and which ideally validates the technical work done. The same may occur when there is a need for technical debt remediation or indeed any other essential technical work.

No one can force work onto a Development Team. They will always agree to deliver something of use, but they must also agree that whatever work they take on is the right thing to do. They may be aware of other things which need doing. Why constrain the application of this principle to 20% of each Sprint?

NB another option is for a Development Team, during refinement, to make the Product Backlog Items being lined up for upcoming Sprints more “expensive” in terms of their estimates. This will effectively reduce Sprint capacity so other important technical work can be done.

Estimates are of course up to the Development Team. Hence this approach amounts to the same thing as having a flexible reservation, but it can be politically easier to implement.

Apologies for resurrecting this old thread, but my situation has changed a bit, but the issues are still very similar.   I thought I would come again to this community to see if there are worthwhile suggestions and/or advice.

The challenge we're now having is that "technical" items are being refined and estimated by the team (i.e. - system logging improvements, application build improvements, code repository changes, etc) and presented to the PO for discussion.   As the team talks about the need and value of such work, the team is relying on the PO to prioritize these items.   

While the PO fully understands the need and benefit of such "technical" work, the PO refuses to "offer" such items to the team, instead remaining fixed on functional delivery.

I know that Ian previously suggested either reserving a % of team capacity each sprint for such work, but the PO feels that such a "reserve" of capacity should be used for functional improvements.   Ian also suggested artificially inflating functional estimates so that such technical work can be absorbed into each sprint, but I don't like the non-transparent aspects of that solution.

Are there any ideas around crafting the message to the PO to help them prioritize this work, or managing these items differently?

Ian also suggested artificially inflating functional estimates so that such technical work can be absorbed into each sprint, but I don't like the non-transparent aspects of that solution.

Estimates should not be inflated artificially - they should genuinely reflect the amount of work which is thought to remain. The downside of the policy I have suggested is, specifically, reduced transparency over the nature of the technical debt, and not over the total estimated quantity of work remaining, which should be clear. In other words, by amortizing the cost of technical debt across the work forecast for upcoming Sprints, the amount of work remaining ought to be fully accounted for on the Product Backlog. However it will not be qualified as discrete, explicit, and obvious technical debt items.

The simplest and most preferable solution is instead:

a) to articulate clear technical debt items on the Product Backlog, and

b) to have a Product Owner who is sufficiently technically astute - and enough of a team player - to prioritize any such debt sensibly in relation to other work.

If that isn't possible - and it very often isn't - then the team may need another policy by means of which they remediate any technical debt they incur. This can mean managing it entirely by themselves in so far as it represents technical concerns.

Reduced transparency over the nature of technical debt may be a consequence of such a policy. There's nothing to stop a team from describing technical debt transparently elsewhere, such as on a publicly available technical debt register. What matters is that the Product Backlog accurately captures the amount of work which is believed to remain. Scrum does not prescribe how individual product backlog items should be identified, and amortization over whatever items a PO cares about may therefore be the least worst solution. However, a policy like this introduces a level of sophistry into a Scrum implementation, something which is always best avoided as far as possible. Far better to have a good PO who is technical when they need to be and a good team player.

Bear in mind that a Development Team can reasonably decide to adopt a zero-tolerance policy for incurring any technical debt at all. They might decide to do so if they have reason to believe it would then be inappropriately handled, for example. They'd be within their rights to adopt such a hard-ball position. No-one can force a Development Team to take on technical debt. However it may not help a PO to maximize value, as short-term business wins could be lost by refusing to compromise.

I think that you are not practicing Scrum very well. Your manager, is not allowed to interfere in the backlog or in the tasks created about the team. The best aproach for this case, is to bring your manager when the team will make the Definition of done, so you guys will put all this considerations clear and transparent to all and this will be considered by the team in all estimates. Every PBI will have to achieve this "technical initiatives ";

Let me correct myself. maybe the best option is to invite your manager to the sprint planning as a non functional requirements specialist, and he will help the team to create acceptance criteria to achieve the pbi as done.

Timothy, I can throw in a suggestion based on my past experience. Note that unlike your scenario (very large organization - multiple POs, etc), we had a single PO and two development teams. Also, in our case we had to deal with technical debt - you mention technical issues (which meay mean much more)

The way we handled technical debt was rather simple. Don't know whether it was a good one or if could've been better. Under the circumstances, the business was rather happy.

• We had various meetings during which possible approaches were discussed.
• Because compromises were very difficult to reach, we decided we use common sense. Because refactoring was an absolute must, business decided the primary focus to be on fixing most technical debt, with a reduced functional focus.
• This was decided because we ultimately understood there's no point in running from the old code, it would eventually catch us and take us down. We also knew it wouldn't take forever, and whenever there was something critically functional that had to be done, we'd switch gears and address functionality over refactoring.
• We started from scratch (yeah, a new sprint 1), and teams reorganized (still 2 teams, different composition)
• It was difficult for all, especially for the PO, as they had to rely on the most senior staff (given their lack of technical skills)
• Took us almost two months longer than expected, but surprisingly, there were absolutely no complaints. And, yes, we did deliver some new functionalities (per MVP) - nowhere near what any reasonable PO would want, but under the circumstances, they had to compromise.

So I guess what I'm saying is while the above is just an example, what may be worth focusing from your perspective is that people (especially PO) should negotiate and reach a compromise.

Hope this helps