Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Technical versus functional effort management

Last post 09:15 am October 9, 2018 by Eugene M
11 replies
10:44 pm January 17, 2018

How do other organizations practicing Scrum manage functional (customer value) work against technical work?

A quick recap of my situation.   In our organization, IT management identifies "technical" initiatives (through independent analysis, strategic decisions, etc.) that are transparent to the business/customers, but are highly critical to the health of our applications (ex: performance, availability, security).   IT management creates and manages these initiatives, advising the PO's and Development Teams so that they understand the priority and requirements of such work.

In the past, they've also tried to educate Product Owners on such technical initiatives, so that being well-informed, they can manage and prioritize this needed work against the functional-value items they usually deal with.   The thing is, some PO's in our organization embrace such technical items, while other PO's serve as a simple pass-thru for this type of work.

The decision was made recently to relieve our Product Owners from having to understand such technical work, so that they can focus more on customer feedback and business value in the work items they manage.   The technical work would be managed by IT Management as a separate intake, and they are going to try and work with the teams without needing the PO's to be involved.

So, a number of concerns/questions from my end regarding this decision:

  1. Should these technical items be maintained in each product backlog, and be selected by the team as part of their sprint forecast?
  2. Should each team allocate a certain % of their capacity for such technical work (either time or story point-based)?
  3. What are some ways to make the technical work transparent, if it is not a part of the PO's backlog or sprint offer?   How can we help the PO plan without having visibility into technical work?
  4. Should such technical items follow a Definition of Ready (similar to functional items), or should another set of criteria be identified for this type of work?

Sorry, but all of this was announced today, and I apologize for what is basically a brain dump of my observations and concerns regarding this decision.   I would love to hear how others have managed similar situations, and am open to any suggestions and/or solutions out there.

Also, I'm tired of the PSM1/PSM2 threads that fill up the forum, and wanted to contribute something to an actual Scrum discussion.   Thank you in advance.


06:09 am January 18, 2018

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


02:20 pm January 18, 2018

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?

 


08:57 pm January 18, 2018

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.


10:34 pm January 18, 2018

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.

 


07:17 am January 19, 2018

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?


09:45 am January 19, 2018

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.


02:55 pm September 26, 2018

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?


04:38 pm September 26, 2018

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.


12:06 am September 27, 2018

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 ";


04:15 am September 29, 2018

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.


09:15 am October 9, 2018

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.