Project Management Central

Please login or join to subscribe to this thread

Sprint Planning - Exploratory Tasks
Network:95



Hi Team

Working on an interesting project where we moving the application from one platform to other. Most of the tasks involved are hit and trial - where the tech team is validating if the porting a component as-is on to the new platform is working or not. If it does not work, they have to do some more work to fix it (which can be infra or code related).

This is posing challenge in sprint planning as the estimates have a wide range and the team really cannot commit to anything till they actually try it out. The same task if it works well, can be done in 1 day vs entire sprint or more if it does not.

Kindly suggest any innovative ideas I can coach my team on to plan the sprint better.
Sort By:
Page: 1 2 next>
Network:47



Seems you partly answer your question already: you know what components are needed to be ported. So start with the sprint to test each of them, and define if additional work is needed. Based on your findings you'll build backlog for fixes and add them to the next sprint.
Network:1910



"Hit and Trail" was called long time ago "The Microsoft Effect". What you describe will not work not matter you try to do to fix it? Why? Because one of the pillars of Agile is quality. Agile in software was created with based on quality. And you are attempting against quality. Agile was created (in software) as an evolution of object orientation and object orientation is based on software engineering and it is impossible to get robust software engineering environments without quality. So, the problem you have must be solve from the view of architecture and quality. I am not saying that you have to stop everything or you have to write documents like a "Bible" in extension. But you have to take a moment (perhaps as long as one sprint) to review architecture. If you do that, I am sure you will solve your problem.
Network:1660



Use a spike to reduce uncertainty and learn. That is a common technique when we have a complex work item which we don't know how to tackle. The spike is time-boxed to a couple of days at most and will hopefully reduce the number of "wrong" paths we would take.
...
1 reply by Prateek Gupta
Nov 07, 2019 7:22 PM
Prateek Gupta
...
Hi Kiron

This sounds closest to our context. Thanks

Do we treat Spike as a special Tech Story in the current sprint and based on the success/failure of it, we pull/push additional work to/from backlog during the course of sprint?

We tried doing spikes one sprint in advance but it is getting complicated. We are inherting a legacy application with about 7-8 years old code. Trying to stand the application as-is in our more secure/protected env and in the processing hitting issues. Once the application is up, we can plan much more structured refactoring and follow regular sprints.
Network:2426



I agree with Kiron- plan these as research spikes with the associated points for the sprint. Once you have identified a solution then create the user stories needed to do the work based on the analysis done in the spike.
Network:76



I agree with colleagues about the analysis task before implementation phase.
As a suggestion, during the research spikes take into consideration the relationship between components to prioritize the most important and indispensable. Depending on how they will be ported, the process of converting the other related components may be influenced for a longer or shorter execution time. The risk management process for the new architecture can help you map the most priority components to begin migration.
Hope this helps.
Network:95



Nov 07, 2019 12:15 PM
Replying to Kiron Bondale
...
Use a spike to reduce uncertainty and learn. That is a common technique when we have a complex work item which we don't know how to tackle. The spike is time-boxed to a couple of days at most and will hopefully reduce the number of "wrong" paths we would take.
Hi Kiron

This sounds closest to our context. Thanks

Do we treat Spike as a special Tech Story in the current sprint and based on the success/failure of it, we pull/push additional work to/from backlog during the course of sprint?

We tried doing spikes one sprint in advance but it is getting complicated. We are inherting a legacy application with about 7-8 years old code. Trying to stand the application as-is in our more secure/protected env and in the processing hitting issues. Once the application is up, we can plan much more structured refactoring and follow regular sprints.
...
1 reply by Kiron Bondale
Nov 08, 2019 6:47 AM
Kiron Bondale
...
Prateek -

Correct - a spike can be used as an experiment to test a given hypothesis (almost like a mini-MVP). If you end up learning that there are no viable options, that might be cause to revise that portion of the solution approach or to negotiate with a PO for pushing back that work item till later. If it is a critical dependency for future features, then how you proceed really depends as you don't want to repeat Einstein's definition of insanity :-)

Kiron
Network:1660



Nov 07, 2019 7:22 PM
Replying to Prateek Gupta
...
Hi Kiron

This sounds closest to our context. Thanks

Do we treat Spike as a special Tech Story in the current sprint and based on the success/failure of it, we pull/push additional work to/from backlog during the course of sprint?

We tried doing spikes one sprint in advance but it is getting complicated. We are inherting a legacy application with about 7-8 years old code. Trying to stand the application as-is in our more secure/protected env and in the processing hitting issues. Once the application is up, we can plan much more structured refactoring and follow regular sprints.
Prateek -

Correct - a spike can be used as an experiment to test a given hypothesis (almost like a mini-MVP). If you end up learning that there are no viable options, that might be cause to revise that portion of the solution approach or to negotiate with a PO for pushing back that work item till later. If it is a critical dependency for future features, then how you proceed really depends as you don't want to repeat Einstein's definition of insanity :-)

Kiron
Network:92



This is something very common in software development that usually happens at the beginning of a software development initiative when you start pretty much from scratch. At this stage everything is trail and error and it is extremely hard to plan and commit to anything.

This demonstrate that in reality Scrum/Agile is not suitable for some some projects that involve software development such as data migration and application migration.

But software development in general is trail and error. When a developer starts working on a task he pretty much starts trying things to implement the requirement then he does his own tests and if the tests are not fully successful he may end up trying another solution.

You problems are purely technical and normal things that happen in software development. There is nothing you can do about it and using Scrum makes things much worse.

The nature of the software development work makes it impossible to commit to anything and as such accurately estimating work is impossible. At the beginning of the project is even harder and while you progress things get easier but software developers can never fully commit to work. That's a fact and there is nothing you can do about it.
Network:2412



Was going to share similar thoughts as Kiron; to utilize a spike story as opportunity to get a foothold on the direction. Ensure it is understand that the spike is to have an output that is able to be showcased to the group, i.e., some quantifiable measure or proven, with all available information, of the direction chosen with the rationale and outcomes tied back to the epic or value stream/prop.
GL!
...
1 reply by Adrian Carlogea
Nov 09, 2019 8:22 AM
Adrian Carlogea
...
I don't understand how this is going to help. The technical experts still have to try different things before they find something workable. It does not matter what you do on the project management/planning side they still have to do the same work.

Also the technical experts when are doing trail and error can't estimate how long it would take and also if they think they have found a good solution after a while they may discover that the solution is not good so they have to go back to the drawing board.

For such situations you need some technical/solution architects and other senior technical experts to work outside Agile/Scrum and come up with some sort of design/architecture to try to implement. Scrum is a disaster when it comes to this kind of work because there is an obsession on delivering something in 2 weeks.

When you are migrating an application or data you can't deliver in iterations anyway, you either deliver everything in one go or you deliver nothing.
Network:92



Nov 09, 2019 7:35 AM
Replying to Andrew Craig
...
Was going to share similar thoughts as Kiron; to utilize a spike story as opportunity to get a foothold on the direction. Ensure it is understand that the spike is to have an output that is able to be showcased to the group, i.e., some quantifiable measure or proven, with all available information, of the direction chosen with the rationale and outcomes tied back to the epic or value stream/prop.
GL!
I don't understand how this is going to help. The technical experts still have to try different things before they find something workable. It does not matter what you do on the project management/planning side they still have to do the same work.

Also the technical experts when are doing trail and error can't estimate how long it would take and also if they think they have found a good solution after a while they may discover that the solution is not good so they have to go back to the drawing board.

For such situations you need some technical/solution architects and other senior technical experts to work outside Agile/Scrum and come up with some sort of design/architecture to try to implement. Scrum is a disaster when it comes to this kind of work because there is an obsession on delivering something in 2 weeks.

When you are migrating an application or data you can't deliver in iterations anyway, you either deliver everything in one go or you deliver nothing.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Seriousness is the only refuge of the shallow."

- Oscar Wilde

ADVERTISEMENT

Sponsors