Project Management

Project Management Central

Please login or join to subscribe to this thread

Sprint Planning - Exploratory Tasks
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 <prev
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.
...
1 reply by Adrian Carlogea
Nov 09, 2019 9:30 AM
Adrian Carlogea
...
My point is that using the Scrum framework or other "methodology" would not help to find a viable solution faster.

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.
Nov 09, 2019 9:17 AM
Replying to Andrew Craig
...
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.
My point is that using the Scrum framework or other "methodology" would not help to find a viable solution faster.

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.
...
2 replies by Adrian Carlogea and Prateek Gupta
Nov 10, 2019 6:26 PM
Adrian Carlogea
...
Since the experts can't estimate the stories as they are trying different things how can you check the velocity? "The same task if it works well, can be done in 1 day vs entire sprint or more if it does not."

The problem here is that they can't estimate. Velocity is completely useless in this circumstance.
Nov 10, 2019 8:56 PM
Prateek Gupta
...
Thanks ! can be implemented fully or in part for sure.
Nov 10, 2019 6:09 PM
Replying to Deepesh Rammoorthy
...
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.
Since the experts can't estimate the stories as they are trying different things how can you check the velocity? "The same task if it works well, can be done in 1 day vs entire sprint or more if it does not."

The problem here is that they can't estimate. Velocity is completely useless in this circumstance.
...
1 reply by Deepesh Rammoorthy
Nov 10, 2019 6:30 PM
Deepesh Rammoorthy
...
I am not talking about estimating without results . I am suggesting that the team should first check what the issues are with integrating within the first few sprints and if they find a pattern, they can include more stories in the next sprint.

The velocity improvement will happen by itself once they complete more stories in the subsequent sprint.
Nov 10, 2019 6:26 PM
Replying to Adrian Carlogea
...
Since the experts can't estimate the stories as they are trying different things how can you check the velocity? "The same task if it works well, can be done in 1 day vs entire sprint or more if it does not."

The problem here is that they can't estimate. Velocity is completely useless in this circumstance.
I am not talking about estimating without results . I am suggesting that the team should first check what the issues are with integrating within the first few sprints and if they find a pattern, they can include more stories in the next sprint.

The velocity improvement will happen by itself once they complete more stories in the subsequent sprint.
...
1 reply by Adrian Carlogea
Nov 10, 2019 6:53 PM
Adrian Carlogea
...
Ok but I don't think this would make the work finish faster or help the team in any way. This is more for reporting.

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. :)
Nov 10, 2019 6:30 PM
Replying to Deepesh Rammoorthy
...
I am not talking about estimating without results . I am suggesting that the team should first check what the issues are with integrating within the first few sprints and if they find a pattern, they can include more stories in the next sprint.

The velocity improvement will happen by itself once they complete more stories in the subsequent sprint.
Ok but I don't think this would make the work finish faster or help the team in any way. This is more for reporting.

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. :)
...
1 reply by Deepesh Rammoorthy
Nov 10, 2019 8:22 PM
Deepesh Rammoorthy
...
I agree. it may not fit a pure agile approach . may need a hybrid.

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.

E.g.
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.
Nov 10, 2019 6:53 PM
Replying to Adrian Carlogea
...
Ok but I don't think this would make the work finish faster or help the team in any way. This is more for reporting.

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. :)
I agree. it may not fit a pure agile approach . may need a hybrid.

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.

E.g.
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.
Nov 10, 2019 6:09 PM
Replying to Deepesh Rammoorthy
...
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.
Thanks ! can be implemented fully or in part for sure.
Thanks everyone for the support ! Appreciate your time, inputs and guidance !
Page: 1 2 <prev  

Please login or join to reply

Content ID:
ADVERTISEMENTS
ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events