Handling epics that only provide a shippable product at the end

Question

i am currently evaluating whether SCRUM would be right for our team. One thing that i do not understand so far and have not found a satisfactory response to is how something like "complete refactoring" epics would be handled.

My specific example: We need to migrate a very large piece of software that has been kept as is on Java 1.4/JBoss 3 to a more current setup. While i can identify tasks in this epic that may be handled during a sprint of say 2 weeks, i could thing of tasks that may leave the product or at least this part of the product not-shippableat least for one sprint.

How is something like that handled? I can't wrap my head around it at the moment so any help to understand this is greatly appreciated.

Kind Regards Christian

Answer 1

"shippable" doesn't necessarily mean "usable by the end user", and it doesn't necessarily mean you actually ship it. All it means is that you're done writing and testing the code, and that it has an appropriate level of quality.

With that in mind, you need to break down your epics into stories that can be completed in the context of a single sprint. Perhaps one story is to port a single program or function to a new version of java. That story will then be broken down into tasks to do the port, write the tests, and so on. At the end of that story, the code should be ported and proven correct with automated tests. Even if that single program can't be used because it has dependencies on other programs, the port of that particular program can be considered done.

More stories would be for porting other programs or functions. Another story might be to switch to something other than jboss, or to a new version of jboss. Again, that work should fit into a sprint. Keep writing stories like this to accomplish all the things that need to happen before the epic is complete. It may be that the very last story is something along the lines of "flip the switch and start using the new code".

With each story you need to identify who the story is for (and it doesn't necessarily have to be an end user), and what the business value of the story is.

Scrum is really nothing more than a mechanism for breaking large projects into smaller projects, with the idea being we can better plan and execute on small stuff better than we can large stuff. And, by completing smaller stories sooner rather than later, we can get feedback that can help us make better decisions going forward.

The other central benefit of scrum is that you don't consider a story done until it is "shippable", but again, that doesn't necessarily mean it's being used by the product, or is visible to the end user. It simply means you're absolutely, completely done with the work for that story.

Answer 2

Agile focuses on value (a.k.a. "solving problems for someone")

Does this refactoring bring value? If not, or if you can't point your finger on it, then you have two alternatives: go back to the drawing board and try to understand exactly what problem you are trying to solve with this, or simply do not use agile for something with such a fixed scope and undefinable value.

Assuming you have a clear idea of the value of this project, and exactly what problems it solves, then focus on those. Apply a "divide and conquer" approach to the problem and value, this allows you to get a series smaller problems to solve and values to be gained.

It is quite rare that, once large problems are well specified, they remain indivisible. If you get stuck with one, ask yourself if you are trying to find a problem to solve or a solution to a problem. In the former case: don't do anything; in the latter, maybe your solution is not the right approach.

For example "We need to migrate a very large piece of software that has been kept as is on Java 1.4/JBoss 3 to a more current setup" is not something you should do without a specific reason! You don't need to migrate anything, assuming you have a working piece of software... are there any actual problems you are trying to solve with this upgrade? Focus on those and consider the migration an optional solution.

I realize the above is quite generic, but your question is also generic :-)

Answer 3

Scrum is only a start point for your process, look at it, keep the bits you like, ditch the bits you don't. It is NOT a religion, (despite many people's insistence on adhering to its holy scriptures).

So, bearing in mind this, the point of Agile as a whole is to remove impediments (like management processes) to enable you to perform your work as easily as possible, however, it realizes that without any management process you may go 'off track', so it introduces a few different processes designed to help you keep yourself organised and working in the fright direction. The main processes that do this is regular updates and team communication.

So this means your epic is "do some work" but you can't realistically do all in one long go without involving a lot of risk (ie when you finished you'll show it, and only then will you know if you did it correctly). So, you break that epic task into smaller pieces that you can show to others to prove that you're still working on the right thing, and that it still fits the desired result.

It can be difficult to understand how to split an epic of 'do an upgrade' into smaller, bit-sized pieces, but I think if you started work you'd quickly be splitting it up anyway. The problem is one of perception, a mental block that stops you thinking about it (like seeing a blank page and not being able to start writing). You can imagine yourself performing the upgrade, and you'll naturally split the tasks up - write them down and you're pretty much done splitting the epic into stories. For example, to do such an upgrade you might have sub-tasks such as provide a new environment, upgrade to latest JBoss, upgrade the DB, document the configuration, test the system, upgrade the code (which in turn gets turned into upgrade each component or layer depending on your system).

Personally I think 2 week sprints are duff, I worked best with 6 week sprints once upon a time, so do not be afraid to change the timing, but do not increase the sprint times to remove the value of them - you need to show progress after each one, or its pointless having sprints at all. And if you don't show progress, there's no point doing Agile. So keep it to reasonable times and release often. If that means pulling a double-sprint now and then, so what - do it. (many people will say "but this will affect your velocity", and I say "sod velocity, its about real progress not management reporting").