Skip to main content

Technical Upgrades

Last post 02:35 pm December 30, 2019 by Mike Van Daele
8 replies
11:21 am July 18, 2013

Our product depends on a third party piece of software and want to periodically update the software to the latest version so that performance enhancements and bug fixes are addressed.

We know we need to set aside some time for someone to upgrade the software and run regressions and track any integration issues.

How would you guys scrum this? Do we need to dig into the changelist of the dependency and pinpoint reasons for the upgrade? Can we simply do it as a constraint? DoD?


04:10 am July 19, 2013

The third party software is not developed by your team. It's a dependency that your team has. This puts it at a higher level than your team's Scrum process. Things like this are generally best handled by larger scale frameworks such as SAFe or DAD.

To be more specific, it's the sort of thing you need to integrate within an agile Release Train. The features and enhancements provided by each upgrade need to be understood, along with the risks, and included in your Product Roadmap. The upgrade dates then feed into the Release Train, which is your plan for incremental delivery.


07:06 am July 19, 2013

Dependencies like this has the potential of breaking many things. We usually do a spike in a sprint where one or more team members update the 3rd party software, run regression tests and verify that everything is working as expected. For the next sprint we know enough to decide whether to proceed or to roll back to the old version. this applies to the IDE and 3rd party components. Test automation is key to avoid a lot of manual testing and to make sure that you can ship after each sprint. Also, since this is high risk we do this as early as possible for a new release.


12:39 pm July 19, 2013

Fredrik, that's exactly what we were thinking of doing. The thing that makes me unsure about it is how we should represent it in our product backlog. We use user stories and sometimes it's not apparent if an update will provide direct value to the customer.

Is this more of the technical wishlist item sort of work or can we somehow write this as a story?


05:50 am July 20, 2013

It doesn't really belong on the Product Backlog unless it provides new features that the PO values. It's a technical dependency in your release train, one which the Development Team are in charge of, and it brings with it the need to assess the upgrade risks.

Fredrik has described a way of managing those risks by a Development Team within a Sprint. Since the team wholly own their Sprint Backlog, they can include whatever requirements they want within it, including technically focused ones for spiking in the way Fredrik suggests.


09:55 am July 20, 2013

> Things like this are generally best handled by larger scale frameworks such as SAFe or DAD.
I completely disagree with this statement. IMO, SAFe and DAD are not really Agile at all, but that's not really on topic with the poster's question. I will add that I'm much more in favor of the scaling ideas from Cohn, Schwaber, and Larman/Vodde.

One way to think about 3rd party component(or service) upgrades is that they *are* requirements in the sense that they are outside your system. A requirement on a system usually occurs at the boundary of a system. Most people understand front end requirements, but back end requirements(when connecting to 3rd party systems) are also requirements, especially when the thing your interfacing with is outside the control of your company.

With 3rd party components, I think you have to ask yourself... Where's the business value in upgrading to the new version? Business value in these situations usually comes down to either a) taking advantage of new features and bug fixes that *your system will **actually** take advantage of/use* or b) there is business value in making sure you are working with a fully supported version of the 3rd party component (but that doesn't mean you have to do every upgrade that comes out -- only ones that are required to get you off of an unsupported version and onto a supported one)

So, Randy, I ask you -- does a) or b) even apply in your situation? If not, what would happen if you did NOT do the upgrade?


04:40 am August 25, 2013

> IMO, SAFe and DAD are not really Agile at all...

SAFe and DAD are like the UK rail network. They are utterly broken and pretend to be something they are not, but thousands may use the creaking infrastructure for part of their journey.


10:28 am May 23, 2018

only ones that are required to get you off of an unsupported version and onto a supported one

@ Charles Bradley : 

I think the original question was more or less dedicated to exactly these kinds of cases (not to interpret the posters intention for him, but at least that was how I stumbled upon this discussion after some googling.. ðŸ˜¬).

If we consider only these cases—passing from an unsupported version onto a supported one—how do you integrate this into your agile flow, if there's no sufficient business value to attach to it? Does "moving to the supported version" automatically have to imply business value?


01:55 pm December 30, 2019

@Johannes Neukamm:

again multiple months later... :-)

According to me, it's up to the business to decide.

I'm a product owner myself, and in cases like that, I would like the dev team to explain to me the risks, costs, benefits etc... of upgrading to a new version or staying at the old.

It's then up to me to decide whether I want to take the risk of staying with an unsupported version (for example) because maybe there are more important things to do at that point in time.

Or the risks are becoming that high, that the value of upgrading is important enough.


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.