Recently I had the experience to estimate an e-Learning course development project based on SCRUM.
Usually I do a bottom-up feature and asset level estimation and the results are more accurate for planning and nailing scope in proposals. This is pain staking and in absence of lot of inputs, I need to rely on best judgment and use collective intelligence of team to identify and scope them. But it has always been worth the efforts. I then tally them into a Gantt based project plan to identify dependencies and factor in schedule and efforts for lead and lag times between teams and tasks. This adds up the cushion to handle project delays and exigencies profitably. Surely, Gantt based estimations shoots up the estimates because of the time the resource gets blocked in non-working times. Then there is a middle ground decided by bosses based on risk factors to ensure there is a winnable proposal.
For first time, I did a SCRUM based resource loading estimation in a recent RFP. I was sure that it is going to hit the roof. Because the initial understanding was that it is another way of resource forecast estimation in a new fad word (just a variation of Gantt based model that I am used to). How wrong could I be ?
The beauty of SCRUM is that the estimation can be done both ways.
1. Estimation through user stories (essentially a bottom-up estimate technique) OR
2. Estimation through SCRUM team composition (Resource based estimation)
And when I used SCRUM for first time, both models, surprisingly gave close match results. Upon analysis, I realized that SCRUM premise and success is in the way idle time gets minimized. This, otherwise gets factored in resource allocation and estimation. Plotting the tasks and resources in Gantt mostly shows that utilization of resources optimally is a big challenge and is a trade off with other parameters either schedule or add in more people to finish few tasks so that dependent resources are ramped up on time.
The foundation in SCRUM teams is that in a Sprint there is no idle time. There are schedule buffers, to account for waiting times between dependent tasks, just in case of a need. With Kanban use, there is always a queue of tasks/features and there is progress of the queue across columns. Each member is expected to move the queue from head to finish by owning their work. This is akin to a conveyor belt of task supply that gets picked by resources in a continuous stream. While tasks may wait for resources, it isn't always the other way around. This is profound. Because task waiting to be picked up doesn't expand the efforts or consume additional resources.
This is the change that SCRUM teams are advantageous about. There isn't a fixed flow. If there is a dependent task that is delayed or not available, instead of waiting for the assigned one, pick up one from the belt that is ready for your work. Thus idle times are minimized. Hence resource based SCRUM team estimation planning nearly and accurately maps to the bottom up estimation.
Further, SCRUM promotes high level of camaraderie between members to assist each other in finishing tasks that are taking longer by a single person. This too makes it possible that there is no waiting or lag time for resources to wait for work.
Bottom up estimation is the default model of SCRUM working. You estimate time and efforts per user story which then rolls up to a final shippable product estimation. So if a task or a feature is in a conveyor belt and not picked up, it just means that productivity has improved in teams. This then gets factored in successive Sprints thereby reducing the waiting times for tasks to be moved in Kanban card system.
Further, clients who are savvy about SCRUM or if you had done a workshop for the clients on SCRUM, you are bound to get good information upfront for estimation. Instead of assumptions, you can readily use user stories to base your budgeting and estimation models.
Sounds great, isn't it. Come onto SCRUM bandwagon and you will realize the marvels of a simple technique that answers age-old problems in estimation of e-Learning projects.
Usually I do a bottom-up feature and asset level estimation and the results are more accurate for planning and nailing scope in proposals. This is pain staking and in absence of lot of inputs, I need to rely on best judgment and use collective intelligence of team to identify and scope them. But it has always been worth the efforts. I then tally them into a Gantt based project plan to identify dependencies and factor in schedule and efforts for lead and lag times between teams and tasks. This adds up the cushion to handle project delays and exigencies profitably. Surely, Gantt based estimations shoots up the estimates because of the time the resource gets blocked in non-working times. Then there is a middle ground decided by bosses based on risk factors to ensure there is a winnable proposal.
For first time, I did a SCRUM based resource loading estimation in a recent RFP. I was sure that it is going to hit the roof. Because the initial understanding was that it is another way of resource forecast estimation in a new fad word (just a variation of Gantt based model that I am used to). How wrong could I be ?
The beauty of SCRUM is that the estimation can be done both ways.
1. Estimation through user stories (essentially a bottom-up estimate technique) OR
2. Estimation through SCRUM team composition (Resource based estimation)
And when I used SCRUM for first time, both models, surprisingly gave close match results. Upon analysis, I realized that SCRUM premise and success is in the way idle time gets minimized. This, otherwise gets factored in resource allocation and estimation. Plotting the tasks and resources in Gantt mostly shows that utilization of resources optimally is a big challenge and is a trade off with other parameters either schedule or add in more people to finish few tasks so that dependent resources are ramped up on time.
The foundation in SCRUM teams is that in a Sprint there is no idle time. There are schedule buffers, to account for waiting times between dependent tasks, just in case of a need. With Kanban use, there is always a queue of tasks/features and there is progress of the queue across columns. Each member is expected to move the queue from head to finish by owning their work. This is akin to a conveyor belt of task supply that gets picked by resources in a continuous stream. While tasks may wait for resources, it isn't always the other way around. This is profound. Because task waiting to be picked up doesn't expand the efforts or consume additional resources.
This is the change that SCRUM teams are advantageous about. There isn't a fixed flow. If there is a dependent task that is delayed or not available, instead of waiting for the assigned one, pick up one from the belt that is ready for your work. Thus idle times are minimized. Hence resource based SCRUM team estimation planning nearly and accurately maps to the bottom up estimation.
Further, SCRUM promotes high level of camaraderie between members to assist each other in finishing tasks that are taking longer by a single person. This too makes it possible that there is no waiting or lag time for resources to wait for work.
Bottom up estimation is the default model of SCRUM working. You estimate time and efforts per user story which then rolls up to a final shippable product estimation. So if a task or a feature is in a conveyor belt and not picked up, it just means that productivity has improved in teams. This then gets factored in successive Sprints thereby reducing the waiting times for tasks to be moved in Kanban card system.
Further, clients who are savvy about SCRUM or if you had done a workshop for the clients on SCRUM, you are bound to get good information upfront for estimation. Instead of assumptions, you can readily use user stories to base your budgeting and estimation models.
Sounds great, isn't it. Come onto SCRUM bandwagon and you will realize the marvels of a simple technique that answers age-old problems in estimation of e-Learning projects.
No comments:
Post a Comment