Hm, I still strugle to see how to turn work like: "Switching from a library X to a library Y because X is no longer maintained" or "Update the framework because current version is no longer supported" to user stories. Users don't usually see any value in these things. They don't care. Waiting until we finish all our user stories, by the boy scout rule, allow us to refactor all places we need to do the change is impossible.
I wonder if in your case it might be something like “Upgrade/Switch from library X to library Y in order to provide a future proof and secure base for user data”? It’s just a thought I had when reading your comment and I may be wrong. I also wonder how you might answer a question like, “In regards to our desire to upgrade our library X, what benefit might a user see from that change either right away or 2 years down the line?”. You might be able to answer something like “We will be able to roll out future changes more quickly” or “The users data will be more secure”. Of course it might also be that there is no current user value, that doesn’t mean that there won’t be user value in future and the story might just stay on the backlog, or surface again in future. Anyway, just my 2 cents on the question. I am sure someone else will provide a much better answer.
I think one can solve this (in principle) by regarding what were misregarded as "technical stories" as instead being about properties or attributes of the system needed to fulfill the user stories. So they go *together*; as an application security person, this is how I see how security is to be built. This does entail revisiting stories from time to time. I see a lot of "cascading failure" from folks accidentally creating stories with implementation details; if one accidentally does this, then, yes, this approach is harder.
Ideally, no stories exist for that and it can incorporated into other work without a specific story. Not saying it is easy though. You can set aside time each week for general maintenance and upgrades and use this time for the upgrade. No shame in that, you don't have to ask for permission. The only thing you have to beware of is that it doesn't take a disproportionate amount of time and it doesn't break stuff. The problem is that we often wait too long to upgrade and by the time we feel the pain, we're looking at an upgrade of 2 major versions: big changes, a lot of time and high risk of breaking things. What you can do is use the Mikado method (Google "understand legacy code mikado method", apparently my comment gets blocked if I include a link) First you find out what steps you need to take to make the upgrade happen and then you apply those changes step by step in day-to-day development and in the time you set aside every week. Every step is fairly safe and goes into production, with every release you get a little bit closer until the upgrade is not such a big deal anymore. If something goes wrong it's much easier to find out what happened and much faster to fix. If you need to upgrade from 3.4.3 to 5.1.0 (just inventing something here), maybe you'll have to upgrade to 3.8.8 first, then to 4.2.7, 5.0.12 and finally 5.1.0, but you'll get there. Every upgrade has value. Could it be that it takes a very long time? Yes, but it's usually not impossible. All the steps in between may feel like a waste, but spending a lot of time upgrading and breaking things will be much more waste in the end. It's the only safe and most productive way. Every upgrade has value, even if it's only "will make the upgrade we actually want easier". You might be able to get to 4.2.7 in 4 hours with minimal changes, but going straight to 5.1.0 would take at least 4 days total with a high risk of breaking things.
@ what do you find not boring ? To have user stories that include by default all the infra related work ? That is the most common approach and is common sense as well. Unless you just re-discovered the wheel.
![Lethal Company Music Video 🎵 "Follow The Orders" [VERSION A]](http://i.ytimg.com/vi/QeooZB4Z7RA/mqdefault.jpg)
Hm, I still strugle to see how to turn work like: "Switching from a library X to a library Y because X is no longer maintained" or "Update the framework because current version is no longer supported" to user stories. Users don't usually see any value in these things. They don't care. Waiting until we finish all our user stories, by the boy scout rule, allow us to refactor all places we need to do the change is impossible.
I wonder if in your case it might be something like “Upgrade/Switch from library X to library Y in order to provide a future proof and secure base for user data”?
It’s just a thought I had when reading your comment and I may be wrong. I also wonder how you might answer a question like, “In regards to our desire to upgrade our library X, what benefit might a user see from that change either right away or 2 years down the line?”. You might be able to answer something like “We will be able to roll out future changes more quickly” or “The users data will be more secure”. Of course it might also be that there is no current user value, that doesn’t mean that there won’t be user value in future and the story might just stay on the backlog, or surface again in future.
Anyway, just my 2 cents on the question. I am sure someone else will provide a much better answer.
I think one can solve this (in principle) by regarding what were misregarded as "technical stories" as instead being about properties or attributes of the system needed to fulfill the user stories. So they go *together*; as an application security person, this is how I see how security is to be built. This does entail revisiting stories from time to time. I see a lot of "cascading failure" from folks accidentally creating stories with implementation details; if one accidentally does this, then, yes, this approach is harder.
Thank you guys for your suggestions. Future benefits & cascading failures is somethong I will try to discuss with the team.
Ideally, no stories exist for that and it can incorporated into other work without a specific story. Not saying it is easy though.
You can set aside time each week for general maintenance and upgrades and use this time for the upgrade. No shame in that, you don't have to ask for permission. The only thing you have to beware of is that it doesn't take a disproportionate amount of time and it doesn't break stuff.
The problem is that we often wait too long to upgrade and by the time we feel the pain, we're looking at an upgrade of 2 major versions: big changes, a lot of time and high risk of breaking things.
What you can do is use the Mikado method (Google "understand legacy code mikado method", apparently my comment gets blocked if I include a link)
First you find out what steps you need to take to make the upgrade happen and then you apply those changes step by step in day-to-day development and in the time you set aside every week. Every step is fairly safe and goes into production, with every release you get a little bit closer until the upgrade is not such a big deal anymore. If something goes wrong it's much easier to find out what happened and much faster to fix.
If you need to upgrade from 3.4.3 to 5.1.0 (just inventing something here), maybe you'll have to upgrade to 3.8.8 first, then to 4.2.7, 5.0.12 and finally 5.1.0, but you'll get there. Every upgrade has value.
Could it be that it takes a very long time? Yes, but it's usually not impossible.
All the steps in between may feel like a waste, but spending a lot of time upgrading and breaking things will be much more waste in the end. It's the only safe and most productive way. Every upgrade has value, even if it's only "will make the upgrade we actually want easier". You might be able to get to 4.2.7 in 4 hours with minimal changes, but going straight to 5.1.0 would take at least 4 days total with a high risk of breaking things.
Great presentation.
Good tshirt
Super boring
au contraire
@ what do you find not boring ? To have user stories that include by default all the infra related work ? That is the most common approach and is common sense as well. Unless you just re-discovered the wheel.