November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
Made no reference to project management or estimating.
My suggestion is for having accountability in determining the possible best path forward toward an unknown, as opposed to 'just trying stuff', as in we did this before so...or I'm an expert, so.....For example, provide a way for architects to assemble what a way forward can be.
We certainly all have our experiences from which we base our opinions. From a community aspect, garnering a variety of experiences and opinions can help others better formulate what they think may work for them in their specific team, project, or organization.
I have worked in such projects and sometimes no matter how good the experts are they have to experiment before they find a good solution.
An IT/software development project usually does not involve scientific research but in some cases some project work ends up being similar to scientific research to some extent.
Obviously when the experts are "trying stuff" they have a plan and are making use of their knowledge an experience they don't just try random things.
In such situations you can't just create User Stories estimate them with points and expect the team to deliver something workable in two weeks time.
As a PM in these cases you can only try to manage as best as possible the stakeholders expectations although is not going to be easy when you have too many unknowns.
I like Yuriy's suggestion
Start with a backlog that only has testing of some or all the components to be ported.
If you have 20 components , start a sprint with maybe 5 user stories relating to the testing of the first 5 components. Test thoroughly . leave no stone un-turned. Don't fix yet. Use this sprint purely to check compatibility.
check your velocity. If you determine that you are going at a good speed, try to include more stories in the next sprint.
When you have covered the testing of each of the components within one or more sprints , you will have a good backlog of what to fix.
Once you have a backlog of fixes, run those "fixes" through sprints, again in the same way....load a subset of fixes in one sprint and check the velocity and improve with each subsequent sprint.
The problem here is that they can't estimate. Velocity is completely useless in this circumstance.
The velocity improvement will happen by itself once they complete more stories in the subsequent sprint.
In my opinion this is a purely technical issue very common when you migrate an application or a database.
I am not sure how such a project works with Scrum but in Waterfall when it gets to the UAT stage the users would come with a lot of complains that the migrated or new application does not work as the old was working. The same with data, in most cases some 5-10% of the migrated data would be wrong if not more.
Application migration and especially data migration are nightmares when it comes to estimating and planning. :)
If in this particular project, you are trying scrum, you need to be a bit more empathetic and humane towards your technical team because they don't know what they don't know. They cannot tell you how long is a piece of string by putting a finger in the air .
Therefore give them some sprints to try out an approach and see if they can make that approach work.
First two sprints - Exploratory/Planning sprints - Stories relating to pre-requisites and Planning . What needs to be in place to start migration? towards end of Sprint 2 , plan the first set of integrations.
Next two sprints - Do the integrations in a test environment. Collect all the defects and put them in the backlog to resolve
Next two sprints - resolve the bugs as part of System testing
and put the system into the UAT environment. Plan out the next three sprints for UAT
Try out the first sprint for UAT . Collect the defects. based on the defects estimate resolution times and then plan the next sprint based on that.
Needs an inspect and adapt approach . Give a high level time frame and then progressively elaborate within those boundaries and if it looks like the time frames may exceed and you may need a couple of more sprints to finish the work , log a change request.
Thanks everyone for the support ! Appreciate your time, inputs and guidance !
Please login or join to reply